On 05/30/2011 09:56 AM, hptf wrote:
Hello all,
I am trying to write an overlay that is able to get the previous/old
values of
an Entity, before it is updated by a modify/delete.
For that purpose, my first tries were to use a search from within the
overlay,
or pre-read.
I try many method, (inspired by existing overlay), but none seems to
work for
now:
- use of pre-read seems to be very complicated; moreover, pre-read ctrl
seems to be returned as already ber-encoded, meaning that I need to
re-decode
the ber to get the value ... this is (too) expensive
This design is incorrect, since the pre-read you add to the request
could interfere with an existing instance of the control issued by the
client.
- use of search from within overlay raise, for now, some problems:
* if using translucent like call to 'be_entry_get_rw' I got deadlock on
hdb
* if using rc = nop->o_bd->be_search(nop,&nrs); from within overlay, it
seems that response is sent also to remote client socket, and not stay
confined
to overlay call ( and, btw, I fail to get the result:
rs->sr_un.sru_search.r_entry is NULL )
You need to prevent response to take the default route by providing your
sc_response callback in the slap_callback structure of the operation
your overlay is modifying. This function needs to do whatever
manipulation the logic of your overlay needs, including using sr_entry,
and then return any logically valid response that is not
SLAP_CB_CONTINUE (which triggers the default behavior, i.e. respond to
the client).
There is plenty of examples in distributed overlays. See for example,
slapo-pcache(5), slapo-memberof(5). If you failed to recognize this I
wonder how you could code an overlay in the first place. Make sure you
recognize how to get rid of resources attached to the SlapReply
structure, which recently changed thanks to the many helpers implemented
by Hallvard.
p.
