OpenLDAP Faq-O-Matic : OpenLDAP Developer's FAQ :
Summer of Code 2008 ideasI think it would be feasible for a student to develop a back-tdb backend. The basic backend functionality could be copied from back-hdb and the caching layers could be omitted, which would leave the code pretty straightforward. Since back-tdb is primarily an in-memory database it wouldn't be much of a performance issue, and it would get us something easy to configure for the very common, less demanding deployments.
Another possibility which I started discussing with Tridge is to modify the
tdb code to always mmap to a fixed address space. In that case we could store
Entry objects directly, with all pointers intact, which would eliminate the
need for a deserialization step on Reads. Then the need for entry caching
would be completely eliminated as well. This is probably a refinement that can wait, and it requires coordinating with the Samba team.
hyc@openldap.org
There are also occasional requests for additional matching rules support, that may be something to add.
Without specifics, I don't see what we can do with this idea. What matching rules?
The Forth based engine also sounds promising.
(From the OpenLDAP TODO list) - the idea here is to create a liblforth engine that can be used by both slapd and libldap to parse ABNF and ASN.1 syntax descriptions and generate recognizers for them on the fly. This would allow new syntaxes to be added to slapd dynamically, without requiring purpose-built C code to be compiled and linked in. The parser should be able to accept a grammar directly copied from e.g. an IETF RFC or an ASN.1 spec and allow its immediate use. We've chosen Forth because it's extremely lightweight, and its extensible Dictionary is a natural fit to the problem.
At the moment, I'm guessing this is bigger than a summer student project.
hyc@openldap.org
At least with LDIF, the format is already well-defined. (Though I agree that it's a pretty miserable format...) I'm not sure what a useful LDIF parsing library should look like. Perhaps one that parsed it into a chain of LDAPMessages.
This kind of ties in to my point that the current LDAP C API sucks. It would be mildly useful to have a library that parses LDIF input into LDAP Request structures. To make it completely useful, the LDAP library itself needs to be built to use LDAP Request structures instead of its current "one function with lots of parameters-and oops we forgot one-design."
hyc@openldap.org
fork/exec in a threaded program is still a dicy proposition, which is one of the reasons we haven't gone there yet. It's also a good reason to phase out back-shell, and promote back-sock instead. It would probably be a small enough job to put an overlay wrapper around back-sock (just like the chain overlay is a wrapper around back-ldap) with some filtering/selection keywords.
I think this is a pretty straightforward project. One just needs to define the desired configuration language for specifying how to select when to trigger an external call. I think it may be as simple as specifying a list of LDAP URLs - any operation whose target entry matches the base/scope/filter of the URL is forwarded to the back-sock listener.
hyc@openldap.org
You mean like the USN code currently in head? ;) IIRC, it still needs a
little bit of work to polish it off.
/repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/usnActually, looking at it again, I'd do it a bit differently now. It should probably be a global overlay instead of a per-database overlay, so that it can publish a highestCommittedUSN in the rootDSE. It also should not maintain its own counters, it should just map CSNs to USNs (which are 64 bit unsigned integers).
By the way, yet another bug in ActiveDirectory, both the Interval syntax and the LargeInteger syntax have the same OID, even though they're distinct syntaxes. (The USN attributes use Interval syntax)
http://msdn2.microsoft.com/en-us/library/ms680871(VS.85).aspx http://msdn2.microsoft.com/en-us/library/ms684426(VS.85).aspx http://msdn2.microsoft.com/en-us/library/ms684427(VS.85).aspxThis should be pretty straightforward too. Hardly a summer's worth of effort though.
hyc@openldap.org