Pierangelo Masarati wrote:
At present, libldap does not include convenience functions for
most (any?) of these extensions... however, convenience functions
are certainly not necessary to make use of any of these extensions
(with a server that supports them). One can encode and
decode the necessary protocol elements using base functions
provided in libldap.
As slapd(8) does implement the client side of LDAP Sync, it would
be nice to extract out its LDAP Sync encoding/decoding functions
into libldap convenience functions. But until then, that would
be your LDAP sync example code (e.g., slapd/syncrepl.c).
As far as I can see, slapd/syncrepl.c already contains a
ldap_sync_search() function, which acts as a LDAPSync asynchronous
request. Maybe it could be renamed ldap_sync_search_x(), so that
ldap_sync_search() corresponds to ldap_sync_search_x() when a NULL context
is passed.
What's not yet isolated is a corresponding result parse function, which is
currently embedded in do_syncrep2().
The rest of the API should take care of filling the syncinfo_t structure,
which should likely be as opaque as possible much like LDAP (LDAPSync?).
In the context of the original question, it would be useful to extend
the Content Sync spec to allow the Persist mode to be requested on its
own. I.e., don't do a Refresh, just start relaying new changes as they
occur. Agents that only care about new events that have occurred since
the agent began execution would otherwise need to maintain context
/cookie history, and go through a Refresh phase that they probably don't
care about.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
