Re: troubles with caps

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Ok, all fixed.

    Speaking of CAPS, we now have all the major components working:
    the client/server IPC model works, and the structural encoding/decoding
    API works.

    It should be possible to start working up replacements for 
    getpwnam() and all its friends.  getpwent(), getpwuid(), getgrent(),
    getgrnam(), getgrgid(), getserv*(), and so forth.

    Basically the idea would be to have libc attempt to connect to the
    appropriate IPC service to do such lookups.  If the IPC service fails
    libc would back-off to a direct uncached scan of the appropriate flat
    file (ie..  so things still work well enough in single-user mode or when
    the system is blown up that root doesn't get locked out).

    This involves:

    * Creating services for password, group, services, and other directory
      services (the resolver being the hardest).  These services would:

      - 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.
      - process requests from clients and return results
      - handle auxillary service interactions, such as YP lookups, 
	automatically.

    * Rewiring libc.

      - Remove direct YP and DBM support
      - 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).
      - Have an emergency fallback mechanism for when the CAPS service is
	not available which does a simple uncached linear scan of the 
	associated flatfile.

    * Starting and restarting services via RCNG.  By default the services
      would generate and maintain DBM files and fall-back to the in-memory
      model if a DBM cannot be created.  CAPS allows the namespace to be
      overloaded, so it is possible to start a new copy of a service before
      killing the old copy without interrupting any users of the service (well,
      the libc code would have to detect the failure and reconnect, but the
      reconnect would succeed because the new service would already be up and
      running).


    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.

						-Matt