[from tech-net]

In article <9412061546.AA17049@kuma.web.net>,
Greg A. Woods <woods@kuma.web.net> wrote:
> [ On Mon, December  5, 1994 at 20:57:07 (-0500), Chris G Demetriou wrote: ]
> > Subject: Re: implementing a name service switch... 

> > I also don't think it's worthwhile putting HESIOD code in the source
> > tree.  I actually am marginally against YP, but a large number of
> > people actually use it.  I see adding HESIOD as adding an awful lot of
> > code-maintenance overhead, for a very, very small gain.
> 
> I'd vote for cleaning out the YP stuff again too, though given the
> headache it is to incorporate (insidious damn stuff, eh!?!), deleting it
> would present a terrible headache for those that must use it.  Perhaps
> they should be responsible for maintaining it....
> 
> Perhaps the same comment should apply to those wanting hesiod.

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().

Another idea would be to move the code to a server (perhaps with a
AF_UNIX^H^H^H^HLOCAL domain socket interface) and have libc access
things that way... then to implement YP or Hesiod or whatver, once would
simply switch servers. In fact, wasn't Paul Vixie  talking about this in
relation to BIND or something?

> On the other hand, would the people who "want" these features be
> appeased by adding something less insidious, that worked with the normal
> system as-is, etc.?  (Eg. something like Perdue's ACMAINT?)

I'm not familiar with ACMAINT. Can you provide URLs for it, or other
references?

-- 
Ty Sarna                 "You know, we live in the age of the superhighway
tsarna@endicor.com        information network thing..." -- Dave Letterman