[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Proxy cache extension for OpenLDAP
Hi,
Thanks for your suggestions on the proxy cache code.
The suggestion to use callback facility to support all the backends without
modifying their codes can save a lot of work. However I am trying to figure
out how to do the following operations required in the cache with this
facility.
1) adding an entry without a parent.
2) deleting an entry with children (without deleting the children).
3) making a search with the search base not in the cache.
These operations are encountered while doing the following:
1) adding to the cache, an entry returned from the backend server, which
does not have its parent in the cache.
2) removing an entry whose corresponding queries have been removed by cache
replacement.
3) while searching the local cache for an answerable query with base entry
not in the cache.
For LDBM backend I could achieve the above by implementing three
additional interfaces for adding/merging, searching and removing. I am not
sure if all of these can be taken care of by the existing interfaces for
search/add/delete/modify.
1) can probably be achieved by adding as root. For 3) the only solution I
could think of was to use the backend's suffix as the search base for all
the cache searches and filter out the entries not in the subtree using the
callback function for send_search_entry. This is not very efficient.
Would greatly appreciate any help in solving this problem.
Thanks,
Apurva Kumar,
Research Staff Member,
IBM India Research Lab
Phone: +91-11-6861100
Fax: +91-11-6861555
"Howard Chu"
<hyc@symas.com> To: Apurva Kumar/India/IBM@IBMIN, <openldap-devel@OpenLDAP.org>
Sent by: cc:
owner-openldap-devel@O Subject: RE: Proxy cache extension for OpenLDAP
penLDAP.org
09/06/02 03:38 PM
> -----Original Message-----
> From: Apurva Kumar [mailto:kapurva@in.ibm.com]
>
> LDAP proxy cache docs in HTML.
Thanks. It's a fascinating idea. The effect of ACLs on cached results isn't
considered though; I guess you assume that all clients of the proxy will
have
equal privileges on the remote server. (That's a fair enough assumption for
many scenarios, it just needs to be stated.)
You can implement your cache_backend APIs without directly modifying
back-ldbm. Look at the callback facility, see backglue.c for an idea of how
to use it. If you use the callback approach that backglue uses, your cache
can interface to any of the existing backends without needing to modify
their
code in any way. sasl.c and saslauthz.c also contain a number of examples
of
how to perform searches using callbacks to execute a variety of different
operations. (This callback facility is very powerful. We used it
extensively
in Connexitor to do a lot of things that normal X.500-based directories
can't
do.) I would very much like to see a version of this code that doesn't rely
on directly extending back-ldbm or any other backends (besides back-ldap).
Also, there should be some kind of cache aging parameter to eliminate stale
data from the cache. A trickle-refresh scheme might be interesting as well,
but that's probably not necessary right away.
It's a very good effort. I think the query containment and query template
approach makes sense. Hopefully some more folks will examine this patch and
chime in.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support