> We need ldapd to do caching for us. Two questions:
>
> a) Is there any technical reason why ldapd doesn't do caching? I'm not
> talking about libldap which does provide caching.
No, there's no technical reason.
> b) Would it be adding caching to ldapd a major change? That is, would
> it be just adding some lines in ldapd's request.c and result.c to call
> libdsap's local_find_entry, cache_entry, and the likes or would it need
> an architecture redesign? Of course, it would include delete_cache in
> modify.c and delete.c to flush updated entries.
It's not major in concept, but the problem is that the dsap library is
set up to do caching for read and list operations. ldap does not have
those operations, emulating then both via search. So, the trick is to
recognize in ldapd when somebody is doing a "read" (i.e., a base object
search), and to use the cache. Similarly, if somebody's doing a "list"
(i.e., a one-level search) one could recognize that and look in the cache.
A compare should be pretty easy.
Another tricky part is knowing when you've got all the attributes for
an entry in the cache. In a simple approach, if I do a base object search
asking for the objectClass attribute, recognize it, cache the result,
and then do another base object search asking for the cn attribute, if
I look in the cache I won't find it. So, you either need to intercept
searches and ask for more than the user wants (which also means you need
to separate the results sent back), or you need to be aware of what's
in your cache, or make it a pass-through-on-failure kind of cache.
Hope that helps. -- Tim