[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl ramblings again
I basically concur.... except I don't think Persistent Search (psearch),
by itself, is all that useful. As LDAPsync does everything psearch does
(and LDAPsync is at least an (experimental) RFC-to-be) and much, much
more, I rather see implemented across as many backends as possible.
I also would like to see all (storage) backends support UUIDs/CSNs
regardless of whether they support syncrepl or not. These are useful in
numerous applications (even those based on simple searches). I note that
the 'last committed CSN' need not be persistent. The server can simply
grab a new CSN at startup and use that as the last committed CSN (as it
will be guaranteed to be greater than any committed CSN).
I'd also like to see syncrepl consumer extended to support other content
synchronization methods than LDAPsync so that slapd(8) can be a slave
of most any LDAP server. For instance, it would be great if one could
setup a consumer to use simple LDAP searches (using time stamps to minimize
traffic) to suck data of some non-LDAPsync provider)... or suck entries
out of a changelog... or whatever.
At 03:32 PM 8/28/2004, Howard Chu wrote:
>This might be a nice project for someone: turn syncrepl provider support into an overlay.
> Right now the code and data necessary to support it are scattered across a lot of files, and tiny changes (like be_context_csn) are hard to keep coordinated, easy to get lost.
> At least Persistent Search should be provided as an overlay, and it would be useful across many other backend types.
> In back-bdb we really don't need the last committed CSN to be stored in a real database entry, we could just search for the greatest CSN at startup time. We could store it at shutdown time, but for the most part it would be better as a memory-only virtual entry.
> The actual search operations that are associated with the syncrepl control aren't "special", they can be performed using a regular search with an appropriately constructed filter. At least, it appears to me that they are not intimately tied to the workings of the database.
>
>Overall I would like to see some more consolidation of this code, and all references to CSNs encapsulated into a component (i.e. an overlay) that is optional instead of hardcoded as it is now. This isolation would help reduce the chance of breakage that is rampant right now whenever some other sturcture definition changes...
>--
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support