> > I haven't looked at the code in question, so this is probably an
> > oversimplification, but the "file" code uses the db(3) routines, right?
> > Why not implement yp or NIS or whatever as dynamicly loaded db(3) access
> > methods, and the switch would simply allow selection of which access
> > method was handed to dbopen().

> there's no reason to overload db's interface any (more 8-).

> If something like this is going to happen, it should have its own
> well-defined interface.


> Note that i'm not strictly against a "switch" type thing which
> controlled loading of lookup methods.  however, that wasn't what the
> proposal was suggesting (at least, so said my reading of the
> proposal...  8-).

Maybe I didn't make myself clear in my `idea bounce'. I basically want
a defined way of:
	a) specifying lookup order, and ensuring that the order asked
	   for is what you get. (I.e, if you ask for bind then files,
	   it works that way)
	b) integrating it in such a way that adding extra support
	   (e.g., hesiod support) doesn't require major hacking of
	   libc functions each time; just addition of possibly an
	   extra library or functions to libc (a'la rpc)
	c) defaulting back to using `files' if the switch file is
	   missing/corrupt
	d) (if possible) controllable in a way that's `standard'
	   (e.g, svc.conf or nsswitch.conf)