troubles with caps
joerg at britannica.bec.de
Sun Apr 25 08:11:38 PDT 2004
On Sat, Apr 24, 2004 at 02:16:57PM -0700, Matthew Dillon wrote:
> - optionally run strictly on the flat file.
> - optionally [re]generate and use DBM files from the flat files when
> the flatfile is found to have been modified and an exclusive lock can
> be obtained on it.
> - optionally cache the flat files in memory instead of generating a DBM
I suppose the optionallies should be replace by "Do at least of the
> - process requests from clients and return results
> - handle auxillary service interactions, such as YP lookups,
Support "stacking" like NSS does. Maybe at support for the NSS API later.
> * Rewiring libc.
> - Remove direct YP and DBM support
- make the entire lookup API fully reentrant.
> - Connect to the appropriate service to perform a lookup
> - Cache results locally so it does not have to perform an IPC for
> every request (CAPS has or will have a mechanism whereby the
> service will be able to notify clients of changes to have clients
> invalidate their caches).
I would skip that part for the moment. This one should be evaluated wether
it is worth the effort. E.g. for uid <=> name mappings most portable apps
already cache them internally.
> I think this would be quite a fun project. It certainly could be done
> incrementally... for example, the services can be written, tested,
> committed long before any libc work is done.
Yeah, I fully agre on this :)
More information about the Bugs