[Date Prev][Date Next]
RE: Overlay Documentation
>> -----Original Message-----
>> From: Pierangelo Masarati [mailto:email@example.com]
>> > 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.
> Good point.
>> 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
> Good idea. A global instance would allow things like ppolicy to truly
> restrict total access to the server (whereas now it can only restrict
> access to a particular backend). This would also solve the problem of
> providing global SLAPI plugin functionality.
... and things like returning the rootDSE could be moved to the overlay
mech, installed by default, so that other overlays could be stacked on it
> The only other sticking point is in post-operation processing. The
> current send_ldap_response() callback mechanism works well as long as
> you don't need write access to the current entry.
Usually, for read operations, if required I duplicate the entry.
I haven't felt the need of post-op in writes yet, but it might be an
> Otherwise, you get a
> deadlock situation if the caller hasn't released its locks before
> calling send_ldap_result(). (This is the problem with back-ldbm
> deadlocking on ppolicy Binds.) In this case, we need to add hooks to the
> frontend, the same way SLAPI does now.
Right. Or backends should send results with entries still write-locked,
and allow overlays to play with the lock and finally release it, or do it
themselves if it didn't happen yet.