Garrett D'Amore wrote: > Sebastien Roy wrote: >> "Not this case" seems appropriate to me. CUPS uses a perfectly modern >> desktop printer configuration tool that has a discovery feature that >> displays local printers (i.e. those that I'd actually want to print to) >> that use modern protocols. This is in contrast to NIS which has an >> incompatible notion of scope (NIS domain) that results in applications >> having access to potentially hundreds of printers I'd never want to >> print to. I'd rather see the printers NIS map Obsoleted rather than >> extended (and focus more on service discovery rather than >> "directory"-based solutions), but that's just my personal opinion. >> Anyway, not this case. >> >> > [ I've removed the case number. Because it's *not* this case as already > noted.] > > I think this question, directory vs. discovery, is a fairly important > one. Certainly discovery based services are often easier for end-users, > but the question is, what other discovery services do we use for things > *besides* printers. Sites that administer all of their configuration in > a directory (NIS or LDAP or whatever) probably want to keep doing that. > Changing the administrative *paradigm* might be upsetting for some sites.
That's an important point -- this used to work, and it's now not going to work, at least by default, and without much of an EOF. Getting back to Sebastien's point, I agree that the way NIS is managed inside Sun with gargantuan printer lists is really annoying and a user-hostile answer. That doesn't mean it has to be managed that way _everywhere_ or that you even have to put up with it. You can modify your /etc/nsswitch.conf if you want to opt out of the local lookup scheme, or even substitute your own priority order there. As for Nico's point about the accessor functions being private, I don't get it. The point I was making was about the high level issue of using the switch versus binding directly with the underlying libraries. The switch provides administrative control over which mechanism is used, and that's a good thing. If the impediment really is that getprinterby* is private, well, then for pity's sake, let's correct that nit. I'm not sure that having every application effectively growing its own embedded equivalent of a name service switch is really the right long term direction. Though it certainly seems to be the way some applications are going. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
