On Wed, Sep 30, 2009 at 04:00:14PM -0400, James Carlson wrote: > Garrett D'Amore wrote: > > 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.
Agreed. > 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. You wrote: Architecturally, though, ... Interface stability attributes and contracts are a crucial aspect of "architecture". The relevant interfaces in this case are not Public, therefore CUPS would need a contract (or perhaps just to reside in ON). The relevant interfaces really should not be Public. We really need a public getprinterbyname(); the private implementations of it in lib/print _probably_ won't do. Which brings us to: it's not likely that we'll develop a public getprinterbyname() any time soon, which means that CUPS, if it uses the nsswitch at all, should do so via the same low-level interfaces used by lib/print. My reply was not intended as a nit, since it's clearly feasible to have a contract for CUPS to use the relevant interfaces. My reply was intended to be informational (since the i-team might well choose to get such a contract, and develop and send a patch upstream for using those interfaces). > 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. I am sure that "having every application effectively growing its own ... name service switch" is NOT the right approach. I agree that several applications (e.g., automounter, lp, sendmail, I think, and maybe one or two others) access the nsswitch via private, low-level APIs, or implement a name service switch themselves outright. I agree that that is not a good thing. I agree that we should correct that, but I doubt that we will any time soon. Nico --