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

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



At 01:24 PM 11/4/2005, Howard Chu wrote:
>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.

Well, LDAP sync operation is for content synchronization not
event notification.  It's not designed for the latter and I
rather not redesign it to serve a second purpose.  For event
notification, something like psearch (expired
draft-ietf-ldapext-psearch), but without the initial
content, would be a better fit.  Or one can watch the
access/audit/change log (with sync or otherwise).

Kurt