Future of the syncrepl consumer

[phillipod]

Given the goal of maintaining parity with the underlying C API in #13, is a syncrepl consumer actually a valid component of core Net::LDAPapi?

There is an opportunity with 3.1 to introduce some sort of server control extension system where server control API implementations could reside..

[quanah]

Sure, syncrepl consumer is a part of the OpenLDAP api, and is implemented in other native language bindings to the C API (See python-ldap for example). I would like to see support even further expanded for delta-syncrepl support.

[phillipod]

Okay, I wrote that at 4am, and it was probably a little terse. Here's my thinking:

Active Directory includes a similar LDAP control to LDAP Content Sync from RFC4533 called DirSync.

Very similar semantics, with a different OID and it can be extended by a couple of other AD controls to achieve basically the same kind of result.

When I said 'valid component of core Net::LDAPapi' I meant that perhaps the syncrepl implementation should be removed from LDAPapi.pm and moved into a submodule - still included with the distribution - and perhaps this could be a fairly generic extension system for server controls that provide hooks to API's exposed from LDAPapi.pm objects based on the detected capabilities of the LDAP server from the RootDSE.

In this way, we can provide implementations for DirSync and syncrepl, exposing the exact same API so code written against OpenLDAP servers works against Active Directory servers with zero code changes - and it has the plus side of ensuring Net::LDAPapi core OO code (LDAPapi.pm) only interacts with defined API's - i.e, an extension API, or the OpenLDAP / Mozilla LDAP API rather than concerning itself with decoding / encoding specific ASN for this control or that control.

Does that make more sense?

[hyc]

One significant difference between Syncrepl and DirSync is that Syncrepl is actually an IETF RFC, part of the LDAPbis series of specs, and DirSync is a sparsely documented proprietary protocol. The two really don't have comparable standing.

[phillipod]

While I agree that open, fully documented standards are best, I disagree that DirSync is sparsely documented - certainly from an LDAP controls and usage point of view, we can have a sane implementation that works:

• Polling for Changes Using the DirSync Control - https://msdn.microsoft.com/en-us/library/ms677626(v=vs.85).aspx
• LDAP_SERVER_DIRSYNC_OID control code - https://msdn.microsoft.com/en-us/library/aa366978(v=vs.85).aspx
• LDAP_SERVER_EXTENDED_DN_OID control code - https://msdn.microsoft.com/en-us/library/aa366980(v=vs.85).aspx
• LDAP_SERVER_SHOW_DELETED_OID control code - https://msdn.microsoft.com/en-us/library/aa366989(v=vs.85).aspx

Regardless though, the purpose of a client library is to provide the functionality users actually need. I'd bet that most of the time, users of listen_to_changes() and next_changed_entries() are really just trying to use a persistent search feature... maybe to create a home drive on an smb share for a newly created user, or to do some other boring, menial task that just needs to get done..

Which brings to mind eDirectory, which implements the LDAP Persistent Search control - https://www.ietf.org/proceedings/50/I-D/ldapext-psearch-03.txt

I view this as more "code abstraction" level than making any particular statement about any one standard over another..

[phillipod]

To clarify - I'm not saying implement a persistent search backend for listen_to_changes()/next_changed_entries() - the deficiencies of that standard in particular are fairly horrible.

[quanah]

Note: currently examining an issue with net::ldapapi and syncrepl that has cropped up with OpenLDAP 2.4.41 or 2.4.42 release.