Re: NT, slurpd, rambling

[Jonghyuk Choi <jongchoi@us.ibm.com>]

>Of course slurpd is soon to be replaced with this client-driven
replication
>stuff that is still under development, so it's not too interesting now.

>But along these lines, we can also build a replicator on top of back-ldap.
It
>just needs to be able to save state for when a target is down, and have a
>manager thread to try and kick queued ops out periodically. Otherwise it
runs
>in realtime. The queue manager can use back-bdb as its backing store,
>similarly to how the LDAP proxy cache works. It can be a simple queue, or
it
>can coalesce multiple changes to the same object while a target is down.

The client-driven replication engine shares some of the features with
what you described with the one on top of back-ldap.
Two modes of operations are provided : 1) refreshOnly and 2)
refreshAndPersist.
The refreshOnly mode is desgined as a periodic synchronization mechanism
between the slave and master by invoking a replication thread periodically
from replication thread pool. By using the backend callback mechanism,
it is intended to work with different backends such as ldbm and bdb.
Replication specification includes normal search criteria such as
baseObject,
scope, and filter. The benefit of the client-initiated replication would
lie in the fact
that the client (slave) knows of its replication status and exchange the
status
with the master to maintain consistency. For instance, this is more
resilient to failure of
replication operation on the wire. With slurpd, neither the master nor the
slave will be
aware of such failure. The client driven replication is status based and
can cope with failure.
The draft protocol is specified in draft-zeilenga-ldup-sync informational
I-D.

- Jong