[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SummerOfCode suggestions

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...

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.
-- 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/