[Date Prev][Date Next]
Re: SLAPI and add requests
>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
>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!
Luke Howard | PADL Software Pty Ltd | www.padl.com