Re: syncrepl simplification

[Aaron Richton <richton@nbcs.rutgers.edu>]

> 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.)

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.

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.)