masarati@aero.polimi.it writes:
Both changes will cause binary incompatibility; the latter will not require to modify custom backends (I've already modified all the existing backends, exploiting in most cases the new feature; in back-bdb there is room for minimal improvement, as DN lookahead is relatively straightforward, so if base/scope is defined, but no filter, some advantages can be expected).
Could you put them at the end of the tool_globals variable instead? Then the binary incompatibility will only be in tool_globals, not in the backend structure. I suppose this variant makes a bit a mess for glue if nothing else - I assume it would need to to save/modify/restore such global parameters. Slap tools could accept these parameters only for backends which which set a flag to say they handle them.
Might even put them in a mostly empty Operation in tool_globals. Some backends may be able to reuse existing Search code that way, and other search-like parameters could be added later if we want. However that introduces incompatibility after all, so maybe that's for RE25. '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat.
I don't think we'll ever need more than a subtree specification. In any case, I think passing those parameters as args rather than as global variables makes more sense. First of all, if you look at the patches,
ftp://ftp.openldap.org/incoming/slaptools-opt1.patch ftp://ftp.openldap.org/incoming/slaptools-opt2.patch
backglue is sort of a nightmare. And it doesn't deal yet with gluing backends that only support one of the methods.
Second, I'd prefer backends not to know about tool global variables, for basic data isolation.
Take it any way 'round, binary incompatibility arises. Option 2 avoids source incompatibility, that's basically what we need. I find it utopistic to expect binary compatibility within the whole life of a minor release. We never guaranteed that, although we tried to preserve it.
p.