[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.
> 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.
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. 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.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support