LDUP Replication Work

["John E. Schimmel" <jes@mirapoint.com>]

Alright, I got around to reading through the drafts for
LDUP, and this is my first attempt to put a list of the
work together.  The following is a quick list of what comes
to mind.

There is a new low-level command that needs to be supported.
They have added the concept of bracketing a set of changes
between a begin/end pair which needs to be recognized.

A unique identifier is now specified on every entry (UUID).
This is automatically generated on every entry created through
the protocol and remains constant through the life of the
entry whether it gets renamed, moved between systems, etc.
I did not see a definition of this identifier anywhere so
if anyone else has let me know, else I'll send a message to
the working group.

A change identifier is attached to an entry every time it
is modified.  The format of this is specified, and contains
a time stamp, a sequence number, and an identifier of the
sytem where the change was made, etc.

The behavior of the delete operation is changed.  Now the
item is only marked as deleted until all replica hosts have
seen the change, and the entry is later garbage collected.
This is to support hierachies with multiple update servers
so that changes can be merged together at a later point.

There is a new operational hierarchy associated with each
managed subtree which contains replication information.  Among
other things it contains replication agreements which state
what system(s) accept modification updates for the tree,
when replication should occur, what method should be used to
replicate the data, what attributes should, or should not, be
sent to each replica, and a vector of change sequence numbers
representing the latest change committed on each system.

Replication my be triggered from either a supplier, or a
consumer.  So the daemon will need to be able to trigger
replication on demand.

Of course LDUP has not been accepted as a standard yet, so
many things are still in flux.

I would like to start by changing some of the simple things
such as attaching a uuid to each new entry, and updating a
change identifier on each change.

Comments?  Thanks.
John
--------------------------------------------------
John E. Schimmel              Voice: (408)517-3418
jes@mirapoint.com          Cellular: (209)631-0896
--------------------------------------------------