Re: SLAPI and add requests

[Luke Howard <lukeh@PADL.COM>]

>Also, note that recently I optimized the modlist handling
>which was turned to doing almost linear normalization where
>its cost used to be quadratic; this made the code little readable,
>so you should be very careful not to break its sematics nor the
>optimization (which was dictated by terrible performances
>when administrating groups with large number of members,
>a hot topic).

I noticed that; you might want to review the PermitModify
changes (if (!permissive) et al) to check that I haven't broken
anything.

>Well, although VERY experimental, I don't think the SLAPI code
>will be extraneous to the main trunk for long (as soon as somebody
>will really need it :), so I'm not against rearranging code
>that's not strictly SLAPI related.  Of course changes should
>be general enough or worth, in terms of simplification, readability
>and against code duplication, to justify them.  Maybe you can try,
>if possible, to protect them behind #ifdefs (say
>#ifdef STICK_WITH_GODOL_STUFF #else ...) so that we can debate
>over them and try to make things as clean as possible.

Understood. I have been careful to date to try and minimise changing
code paths for where LDAP_SLAPI is disabled, but (OTOH) have been 
quite agressive in rearranging the SLAPI code as our plugins need
a lot of the Sun ONE DS 5.x API (and some things are very difficult
to do under the constraints of the 4.x API, which IBM implemented;
for example, returning an array of struct berval pointers to the
plugin which it doesn't have to free, now that the internal representation
is a BerVarray; there is new API for 5.x which is more opaque).

Although not strictly necessary, I'm ostensibly hoping that our 
plugins will be *ABI* compatible with Sun ONE DS (ie. no recompile).

Anyway, I'm rambling... must be all that coffee... SLAPI, though,
is so very very useful!

cheers,

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com