Re: syncrepl simplification

[Howard Chu <hyc@symas.com>]

Aaron Richton wrote:

> > I vote in favor of a single context.  Among the few odds I don't
> > understand of syncrepl, there's the usefulness of the "attrsonly"
> > parameter to searches, the usefulness fo the size/time limits and so.
> > In my opinion, if the aim is to have a replica of a database, the
> > updates should be performed with essentially unlimited  administrative
> > privileges.  I might be missing something, or others may have a much
> >    
>
> attrsonly and certain limits, like time, make very little sense. (I could
> make an argument that a time limit might stop a runaway process, but I'd
> sooner leave that to the operating system, ulimit or such.)
>  
Agreed.

> I've found it important to have data limits, eg certain parts of the tree
> and/or attributes, available. In practice, however, I find myself
> implementing those on the server side, and giving the slave maintainer
> some DN with not-quite-everything visible as the syncrepl bind DN. I'm not
> even sure if the client-side functionality (which is there with the attrs=
> directive) is strictly necessary.
>  
Well, part of the idea behind syncrepl is to eliminate the need to 
explicitly configure replication agreements on the provider. While you 
can certainly control access to data on the provider (using ACLs and 
whatnot) you wouldn't want to be forced into making a lot of special 
settings on the provider for the purpose of limiting replication. As 
such, the client-side attrs= option makes sense.

> Going to a single context sounds like a good idea. If I'm not missing
> something, I think this might also allow for the rid= parameter to go
> away, which is a big win from a usability perspective (no more phantom
> cn=syncreplXXX entry, no more thinking up fresh RIDs, etc.)
Yes, that's been very inconvenient and I'd like to make it go away.

re: limits - sizelimits are a particular problem; since entries are not 
transmitted in entryCSN order, any refresh phase that is interrupted by 
a sizelimit is essentially wasted. The provider only sends a fresh 
cookie at the end of the refresh phase because it can't be incremented 
safely during the refresh. As such, incremental refreshes are 
impossible. (This problem could be solved if we had server-side sorting; 
the provider could send entries in entryCSN order then, so it could send 
a fresh cookie with every entry.)


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