More on system lookup daemon

[Eli Green <eli@xxxxxxxxxxxxxxxxxxx>]

Well, I've finally managed to book enough time on my own computer (lousy
roommates...) to start experimenting with caps and I've been mulling
over the design of the NSS type daemon.

NSS (at least on Linux, where it is as well documented as any other part
of Linux), it seems that they just dynamically load function pointers
based on the C library function you want to call. For example, the
compat module would be a shared library with _compat_getpwent symbols,
or something like that.

That's fine for something that gets dynamically loaded into your own
process space and you get the joy of using all the globals you want, but
doesn't really work in the case we're looking at.

So right now I'm imagining a forward-only cursor system. The only entry
points into a module would be:

	typedef struct query_op {
		char *field;
		char *value;
	} query_op_t;

	typedef struct query {
		char *db;
		struct query_op *ops;
	} query_t


	cursor_t
	cursor_init(query_t *query)
	{
	}

	void *
	cursor_next(cursor_t cursor)
	{
	}

	void
	cursor_destroy(cursor_t cursor)
	{
	}

query is meant to be encodable by CAPS IPC, naturally. getpwuid, for
example, would simply provide a query struct looking something like
{"passwd", {"uid", "5"}} to cursor_init and call cursor_next once.

While this makes it very easy to implement modules (it should be
possible to write an NSS compatibility module and it would be very easy
to write SQL or LDAP modules), is it worth having such a generic
interface when cursor_next is going to be returning database-specific
pointers anyway?

(Or is it? Could it just return key-value pairs, and based on the
database requested, the daemon itself could then pack them into structs
before sending them back to the client?)

Please let me know in the harshest language available if I'm being an
idiot here.

(Oh, I assumed cursor_t would be something small, a 32 or 64 bit int, to
be used by the module as it sees fit).