lookupd-style daemon

[Ivan Voras]

Eli Green wrote:

Would it be more clever to take advantage of the fact that we have a
persistent daemon that can maintain connections to database servers (I'm
thinking LDAP and SQL here) and cache things in memory, or would it be
in the best interest to be able to load other NSS modules?
Personally I'd rather do the former. The API for writing modules really
shouldn't be that complicated, IMHO.
If I understand you correctly, than "both" would be useful. You'd 
probably have a configuration file, something like:

source_name=My NSS LDAP server {
   type=nss
   load=nss_ldap.so
   cache_timeout=30s
}
source_name=My SQL thingy {
   type=internal
   load=my_mysql_thingy.so
   cache_timeout=1min
}
source_name=My passwd file {
   type=passwd
   read=/etc/passwd
   cache_timeout=0
}
(but then again, you could just make a MySQL NSS library/provider and 
not have two separate cases).

I'm assuming, given the stated goals of the project, that libcaps
automatically provides network-transparent IPC, so the lookup daemon
could be sitting on a remote machine. Is this correct, or should the
daemon itself be able to forward requests to another machine and maybe
cache the results locally?
LDAP itself can be configured to pass requests to other LDAP servers.
There's also a small issue with cache_timeout: if you have local 
cache_timeout of 30s and configure it to contact another instance of 
lookupd that also caches it for 30s, could the data get 1 minute stale?

Otherwise, it would be cool, but not terribly useful to have it sit on a 
separate machine (network bandwith and latency are the reasons why other 
projects such as Linux and FreeBSD are making their own local-caching 
nss daemons).