Re: SummerOfCode suggestions

[Howard Chu <hyc@symas.com>]

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