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
-- 

Reply via email to