[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Move SLAPI in an overlay...

> 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.

I've done something similar with an overlay (that implements the memberOf
stuff "a la AD") which I didn't commit yet because after a long debate
with Kurt we agreed that it needs some work yet.  In that case, I needed
to preserve groupOfNames entries from deletion because in case of success
I had to use their member to remove the references from the member
objects; in this case, I was keeping a copy of the member around and, in
case of successful delete, using it to do the rest of the work in the
overlay's response.  It had to be done __after__ because the delete had to
succeed first (if you want to play with it, I can send you a copy; I'll
commit it as soon as I spare some time to solve the issues I mentioned
before).  Not extremely efficient, but fine.  I guess Howard does
something similar in slapo-refint.

I think if you do know in advance what the result of an operation will be,
and you can speculate enough about the expected results you intend to
handle, I think the current mech is enough.  For instance, for your
problem you could just intercept the delete in foo_op_delete, do an
internal search (possibly as the rootdn), copy the entry if it exists and
store it somewhere (I think I used the ldap_pvt_thread_pool_[gs]etkey to
keep it 'round the operation); then, in case of success, in foo_response()
do what you need, otherwise just delete the copy.

Replace the foo_* calls with the appropriate actions done in the
corresponding slapi_over_* calls.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497