[Date Prev][Date Next]
RE: Overlay Documentation
>> -----Original Message-----
>> From: Pierangelo Masarati [mailto:firstname.lastname@example.org]
>> > At 10:26 AM 3/18/2004, Howard Chu wrote:
>> >>> I think we
>> >>> should focus on
>> >>> the maturity of native interfaces (e.g., ensuring the native
>> interfaces are
>> >>> encompassing of our needs and well documented).
>> >>I agree. I think we're still figuring out whether or not the native
>> >> interfaces are suficient...
>> > One sign that the native interface is encompassing will be
>> > when SLAPI compatibility layer can be (and hopefully will be)
>> > implemented as a module interacting with SLAPD over the
>> > native interface.
>> My sensation is that SLAPI calls can occur in far more places
>> than overlay ones;
>> the latter are confined to after a database is
>> selected, and along
>> the path from front-end to backend and vice-versa. SLAPI can also act
>> before database selection. Everything else occurring after database
>> selection should be possible with overlays as well.
> Yes. There's also the side-wart of SLAPI ACL plugins...
but you can work it around in most cases, because you can add acl checks
at any time both from frontend to backend and vice versa.
>> however that by
>> using back-relay in its current implementation, one should be able to
>> interact with the request BEFORE real database selection, at
>> the price of
>> unnecessary DN rewriting because one needs to mask the real
>> naming context
>> used in the real databases. Maybe we could simply add a
>> stack of overlays
>> BEFORE the database is selected?
> One could create a relay instance with suffix "" and push everything
> under it, yes? Just an idea...
This is going to work only if you accept to use fake naming contexts and
rewrite them to the real ones; we could also use the overlay API to
process things before invoking the real database calls; sort of having a
global slap_overinst which, if not null, contains a stack of overlays, and
each operation needs be processed by it before getting to backend