Re: syncrepl simplification

[Howard Chu <hyc@symas.com>]

Kurt D. Zeilenga wrote:

> At 09:19 PM 1/12/2005, Howard Chu wrote:
>  
>
> > Kurt D. Zeilenga wrote:
> >
> >    
> >
> > > The rationale, I believe, for multiple consumer contexts
> > > within a database context was that administrators could state
> > > different consumer policies for different areas of the DIT.
> > >
> > >      
> > I'll have to think about that some more.
> >    
>
> I've been, too.  In particular, I think the above rationale more
> applies to provider contexts, where one might want to have different
> server handling of different requests.  For instance, one might
> want to have one area covered by a session log and one area not.
>  
That actually makes sense, although the current code doesn't allow for 
this. It would require the sessionlog config directive to take a search 
specifier (baseDN of a subtree at least) to differentiate logs. Again 
this is problematic when you're dealing with ModDN requests; if an entry 
moves across a sessionlog boundary then one or both logs becomes useless.

At the moment all updates in a context are recorded in all the active 
sessionlogs, so the only difference between the multiple logs is their 
size. This also seems unnecessary, it would be best to have a single log 
of the largest practical size. I have a feeling this sessionlog stuff 
was not thoroughly thought out; the fact that there is no config keyword 
for the sid on the consumer implies to me that it was never even tested 
before.

Given all of this, I think it would be best to have only one sessionlog 
per provider, and we can forget about the sid parameter entirely.

> On the consumer side, we just just require additional
> database contexts where the admin desires different consumer
> policies.
>
>  
>
> > To me, it still sounds like a recipe for disaster. If the separate consumer contexts are talking to different providers, then you have the cascade problem I mentioned before. If the contexts are all pulling from the same provider, then I guess it works. I still don't see any rationale for the updatedn on the consumer; surely any data that the provider returns must satisfy the consumer criteria and therefore must be reflected into the consumer DB.
> >    
>
> I concur with regards to the updatedn.  Also, we need to revisit
> consumer ACLs.  Seems odd to me that syncrepl consumer needs
> permission to write into its own database.
>  
Yes. OK, I'm going to delete the updatedn stuff then.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support