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
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
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
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
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
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
This should be pretty straightforward too. Hardly a summer's worth of effort
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/