[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Refactoring LDAPSync API out of slapd (Was: asynchronous event notification?)



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/