troubles with caps

[Joerg Sonnenberger]

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
> 	file.

I suppose the optionallies should be replace by "Do at least of the
following"?

>       - process requests from clients and return results
>       - handle auxillary service interactions, such as YP lookups, 
> 	automatically.

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 :)

Joerg

> 
> 						-Matt
>