Howard Chu wrote:
Howard Chu wrote:
I recall we had a few ideas last year, but they came up a bit late. Anyone still have some wish list items for this year?
The application deadline is two days from now, so let's try to summarize and elaborate where needed within the next 24 hours.
I 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.
I think the above would be a pretty useful project as-is.
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.
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.
At the moment, I'm guessing this is bigger than a summer student project.
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.
(Perhaps that should be an SoC project too.)
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."
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.
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/usn
Actually, 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. Idiots... http://msdn2.microsoft.com/en-us/library/ms684426(VS.85).aspx http://msdn2.microsoft.com/en-us/library/ms684427(VS.85).aspx
This should be pretty straightforward too. Hardly a summer's worth of effort though.
That looks like all the ideas so far. For each idea, we will also have to have mentors to work with the students. So post here if you're interested in that as well. I'll set up a FAQ-o-Matic page for whatever we decide on.