Overlay and overlaying (Was: SLAPI support is a pain)

["Pierangelo Masarati" <ando@sys-net.it>]

> As I filed ITS#2747 it struck me that we'll be having to take SLAPI into
> account in too many different places. It shouldn't be this way, this is
> going to get out of hand fast. It would really be a good idea to
> identify all the kinds of hooks we want to support for SLAPI and provide
> a single point of access to them, so we don't have to worry about this
> kind of oversight down the road.
>
> Since my take on SLAPI plugins at this point is that they are always
> associated with a particular backend, it makes sense to me to
> encapsulate their invocation in a slapd overlay, so that the SLAPI code
> only intrudes when it's actually configured by an admin.

Talking about overlay and overall architecture, I'm finally
back from my "sabbatic" and I'd like to address a couple of
things (as oon as I re-get in touc with HEAD code).
I couldn't have overlay to work, so I digged into it and I
had to fix or change a couple of things.  I dont know if
anybody found it, so I'll commit my fixs soon for review
(or I'd rather pot a diff, so you can review before commit).

Moreover, I found out that to support stacked callbacks we'd
need to deal with automtically/dynamically allocated data in
a reliable way.  After some unsuccesful tries, the best I could
figure out was a set of flags to say what data is temporary,
and thus can be freed if not neded any more, and what's
read-only, and thus a copy is to be made before massaging.

I came into this while writing a dn massage overlay, which
needs to massge entry's dn (and sometimes some attributes),
while entries are usually read-only (but are not, for instance,
when returned by back-ldap).

I think this is also a problem for SLAPI, which in many cases,
for "binary" compatibility, must rerrange data in "legacy"
structures, or copy them for no sake.

My approach would reuire to add (to the response structure,
SlapReply, or to the entry itself) a flag/set of flags, and
use them consistntly in overlays and when returning entries.

I first considered adding flags in SlapReply that states
whether some of its data is to be freed or not (e.g. error
mssages and so, when replaced by other, more appropriate
messages along the stack); but then I ran into the problem
of how to free them: some of the mssages are allocated by
ch_* routines, some on *ctx routines, some on LDAP_MALLOC()
or even on LBER_MALLOC().  I know using free() usually does
the job, but i really lost insight into memory allocation.
Some handbook or giudelines would definitely help.

I guess I mixed (too) many topics while hijacking a message,
sorry for that.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it