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. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------