h.b.furuseth@usit.uio.no wrote:
ando@sys-net.it writes:
I think bi_entry_get_rw() needs work.
Or maybe phase it out in favor of some other call?
In fact, as also discussed in ITS#5628, callers either return the entry or have no means to modify the arguments of the request.
It has more troubles than that. See e.g. the notes about passing rw=1 (write) to it here: http://www.openldap.org/lists/openldap-devel/200803/msg00055.html And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which says to pass an rw=1 argument to bi_entry_release_rw().
Well, I see many places where an entry needs to be fetched. Typically, it needs to be done read-only. So the difference between bi_entry_get_ro() and an internal search is that if we are fine with the entry in-cache, we save lots of manipulation. However this might no longer suffice when overlays muck with the entry (like slapo-rwm). Moreover, when overlays are present, I see the need to: 1) run it like it came from outside, going thru all the overlays 2) go straight to the underlying database 3) go thru overlays starting at some point (e.g. when called from inside an overlay under the assumption the entry is fetched as that overlay would see it, so with only any possible mucking from overlays layered deeper than the caller). This probably needs to modify the way callbacks are actually called, allowing some "after self" feature in playing not just the overlay list, but also the response (and the cleanup).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------