Re: Move SLAPI in an overlay...

[Luke Howard <lukeh@padl.com>]

>Another thing, it would be good to move the Slapi_PBlock out of the
>Connection and Operation structures and into the SLAPI overlay's
>private data.
>
>This could be a little tricky though.

Done, what's tricker is moving the SLAPI extension information outside
the connection/operation structures, but it is probably possible. A
better approach might be to generalize connection/operation extensions
so they can be used by overlays, too. grep "#ifdef LDAP_SLAPI" *.c|wc
is now down to 20 in the frontend, so it's an improvement at least.

Has anyone thought about having overlays at the database layer? It
would be useful if plugins could get "closer" to the entry before it
is committed to disk and/or have access to the underlying database
transaction.

For example, a plugin I'm working on needs to be able to do things
like intercept an entry delete, and turn it into a modify/modrdn to
move the entry to a tombstone container (modify to strip the entry
of most of its attributes, modrdn to do the move). It's possible to
do this with SLAPI today, without any transaction safety. But even
if LDAP Transactions were supported, I'm not convinced that it would
be the right approach, because (for the example I gave) one ends up
duplicating a lot of protocol-related code.

Also, the plugin needs to handle replication conflicts, and this
usually requires transaction-safe access to the existing entry(s)
with the same name and/or UUID as the replicated entry.

-- Luke

--