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