On Wed, Sep 30, 2009 at 01:15:32PM -0400, James Carlson wrote:
> Norm Jacobs wrote:
> > Milan Jurik wrote:
> >> NIS is not Solaris specific feature and fully supported naming service
> >> with no EOL plans. Why should admins mantain another naming just for
> >> printing?
> >>
> > NIS is not Solaris specific, but our printers.conf.byname NIS map is.
> > The name service support in CUPS is more dynamic and actually
> > requires less admin work than NIS does for printing under Solaris.
>
> Architecturally, though, if it went through the name service switch
> rather than linking directly with the protocol-specific libraries, it
> should work fine with NIS, LDAP, or any other NSS-supported feature.
Architecturally it couldn't really, since the relevant name service
switch interfaces are not, so far as I can tell from a cursory look,
Public.
In fact, there are two private-looking implementations of
getprinterbyname() in ONNV, like this one from
$SRC/lib/print/libprint/common/nss_printer.c:
int
getprinterbyname(char *name, char *linebuf, int linelen, char *ns)
{
nss_XbyY_args_t arg;
nss_status_t res;
private_ns = ns;
NSS_XbyY_INIT(&arg, linebuf, linebuf, linelen, str2printer);
arg.key.name = name;
res = nss_search(&db_root, _nss_initf_printers,
NSS_DBOP_PRINTERS_BYNAME, &arg);
(void) NSS_XbyY_FINI(&arg);
private_ns = NULL;
return (arg.status = res);
}
There's another, similar one in $SRC/lib/print/libpapi-dynamic/common/nss.c.
And that's not enough, since one then has to parse the result (see the
two _cvt_nss_entry_to_printer() implementations in the same two
libraries).
Of course, CUPS could get a contract to use those low-level name service
switch interfaces. Or we could make a Public getprinterbyname(). The
former seems more likely at the moment; anyways, I recommend it.
Nico
--
