Slurpd and syncrepl really took opposite approaches to replication. While
syncrepl allows consumers to be configured without any special configuration
of the provider, slurpd allowed slaves to be configured without any special
knowledge. This feature allowed slurpd to be used to replicate to pretty much
anything that understood some flavor of LDAP.
With syncrepl, the consumer must minimally understand entryCSNs, entryUUIDs,
and a contextCSN. This requirement would appear to limit our reach. But with
delta-syncrepl, we actually need nothing more than a contextCSN to keep track
of where we are in the changelog. And when using delta-syncrepl thru an LDAP
proxy, there's actually no requirement that we store the contextCSN on the
remote server.
We could simply store the contextCSN as a DB-specific attribute of the proxy
DB's entry under cn=config. Whether we do this by explicitly modifying the
syncrepl code, or by using an overlay to accomplish the sleight-of-hand
doesn't seem to matter much. (Though there may be more uses for a
customizing/mapping overlay here; e.g. translating LDAPv3 schema to MS AD.)
Just wanted to mention this here before I forgot it again.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
