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

Re: eXtreme customization of slapd

Pierangelo Masarati wrote:
I have some requests for further slapd customization opportunities.
Some of the customizations are really "custom", in the sense that they
could break syntax and schema checking the way it is done now.  In some
cases even decoding the packet could break, so I'm a bit hesitant and
I'd like, if possible, to be able to design custom code as little
intrusive and as advantageous for OpenLDAP as possible, even at the cost
of heavy slapd rewriting that is of general usefulness.

First idea:

instead of calling do_*(), add yet another pseudo-database layer, much
like the "frontend" database, called the "decoding layer" database,
which could be replaced (rather than augmented) by other analogous
components.  In this case, the custom slapd could do almost everything
to an incoming packet, as soon as it is presented to the frontend and to
the backends in a consistent manner.  Advantages: total freedom;
disadvantages: risks lots of code duplication and so.

We've talked about adding completely new protocol handlers on the frontend before. E.g., a X.500 DAP handler, or a DSML handler. It would take a small bit of restructuring in connection.c to set up some tables of handlers. (Right now we sort of do this already, as client sockets already get handed off to custom functions for their I/O events.)

Second idea:

"staggerize" packet decoding.  For example, when a request comes in,
just decode the DN; "sanitize" (i.e. parse and validate) it as little as
possible; then pass control to an intermediate layer, which could
actually be an overlay, right after database selection.  At this point,
it would be up to some code at this layer to do the rest of the
decoding, including relaxing some checks or allowing some violations (I
believe this is part of some requests from the Samba developers, and
similar issues were raised by Luke Howard with respect to compatibility
with some M$ "extensions").  Advantages: could be a first step towards
per-database schema; potential for less code duplication.
Disadvantages: could need extensive work to split current code as required.

I'm less convinced about this, but given the ability to handle the previous suggestion, there's really nothing stopping it.

As far as breaking the rules for packet decoding, that doesn't make a lot of sense. If this is LDAP and a packet is supposed to be in BER form, then that's that, it must follow the BER. If it's not valid BER then it's not LDAP. Whether that matters, in the context of modularized protocol handlers, is up to you.

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