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/