Figuring out what the story is with LDAP notifications isn’t terribly easy. There are a number of different protocol extensions out there:
- Netscape’s Persistent Search or PSEARCH. Fedora Directory Server supports this. Extends the standard searchRequest such that it doesn’t complete immediately, and returns any changes to the matched by the search.
- Triggered Search Control or TSEARCH. Not sure what implements this. Similar to psearch.
- Microsoft LDAP Control for Directory Synchronization or DIRSYNC. Implemented by Active Directory, but requires the client to poll for changes.
- LDAP Content Synchronization Operation or SYNC. Implemented by OpenLDAP and allows both polling and persistent modes.
- LDAP Client Update Protocol (RFC 3928) or LCUP. Similar to SYNC. Not sure who actually implements this.
The strangest thing about all this is that LCUP is the only one of these that progressed from Internet Draft to RFC, yet neither OpenLDAP nor Fedora Directory Server implement it. SYNC seems to have been proposed by the OpenLDAP crew because when they went to implement LCUP they found that it “requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes”, which presumably wasn’t something that OpenLDAP already did. Yet the working group went ahead and progressed LCUP to RFC and not SYNC.
Anyway, moral of the story is that if you want notifications, then you want PSEARCH if you’re using Fedora Directory Server and SYNC if you’re using OpenLDAP.
If you’re using OpenLDAP’s client library, rather than the Mozilla LDAP C SDK, then it’s a little tricky since you have to manually create the psearch control and parse the entryChange controls. Here’s some example code.