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.