Hi,
some feedback on what we have done this week :
- the control codecs have been implemented (almost, the syncStateControl
still has to be codec).
What we need now is some few more bricks :
- UUID from RFC 4530
- Injecting CSN and UUID in every entry
When we will have those guys, we will be ready to grasp the big
remaining part ...
<note>I still have to read again the RFC to check if we need the
changelog for deleted entries. IMO, it's a necessary part, as otherwise
the protocol assume you transmit all the present UUID on the producer in
order to do a diff and deduce what are the removed entries...</note>
I would suggest that we write a small client application (nothing
serious, something very rough, not even a GUI) to send requests using
those controls to an OpenLDAP server, as it supports RFC 4533
(syncRepl), just in order to get the network layer whipped. As soon as
this client will work, we will have to inject it into the server, as a
part of the replication consumer. At this point, I would suggest we use
MINA 2.0 Connector to deal with the connection.
When we will have the communication up and running, with all the
protocol debugged, we will be able to move to the next stage : managing
the injection of the incoming entries into the consumer base, after
conflict resolution. It's the biggest part...
What else ? We will need a mechanism to recover the connection if it
fails, that's for sure. We also will need to update the configuration.
Last, not least, OpenLdap has a delta syncrepl system which is much
better that the standard SyncRepl, as it transmit only the changed
attributes, instead of the full entry. We might want to study this.
Did I forgot something ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
