[Date Prev][Date Next]
Re: (ITS#6442) slaptools iteration enhancement
> email@example.com 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,
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.