Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation

[Till Kamppeter <till.kamppeter@gmx.net>]

Norm Jacobs wrote:
> Till Kamppeter wrote:
> 
>> I tried the trick with the links. I did
>>
>> -------------------------------------------------------------------------
>> [root@majax c]# mv /usr/lib/libpapi.so.0.0.0
>> /usr/lib/libpapi.so.0.0.0.orig
>> [root@majax c]# ln -s /usr/lib/psm-ipp.so /usr/lib/libpapi.so.0.0.0
>> -------------------------------------------------------------------------
>>
>> And then I got a lot of output with "printer-query", all CUPS-specific
>> options and settings, but still one important thing missing: The options
>> in the PPD file. So I cannot build a complete printing dialog with the
>> info which I can poll with PAPI and this is very important for the
>> standard to be adopted.
>>   
> 
> The PPD file data via a capabilities interface is something that Wendy
> is working on.  I don't know that there is an ETA yet.

What is an ETA?

> 
>> Another thing is taht if I have queues which are broadcasted from remote
>> machines to my local CUPS daemon, "printer-query" cannot poll info about
>> them at all. It tells that these queues do not exist.
>>   
> 
> The PAPI implementation in psm-ipp.so will contact the IPP server
> that is either the "default" compiled in service, specified via environment
> variable (IPP_SERVER, CUPS_SERVER) or via the destination name. Eg.
> 
>    papiPrinterQuery(svc, "ipp://server/printers/queue", ...);
> 
>    $ lpstat -p ipp://server/printers/queue -l 2
> 
> Part of the attraction of the libpapi-dynamic implementation is that it
> will
> enumerate print queues from a configuration db/name service and resolve
> names to uri's on a variety of print services across multiple hosts.  To
> solve
> the update problem with CUPS browse protocol, I prototyped a CUPS browse
> listener that can be run to keep /etc/printers.conf up to date.  The right
> way to do this on systems with CUPS running would be to have CUPS make
> the configuration updates via the "PrintcapFormat" directive.  I can supply
> diffs for this as well.  I run both Solaris LP and CUPS on my laptop
> side by side
> with a mod for this.
> 

A standard CUPS frontend like kprinter shows all printers available via
the local or selected CUPS server, including the ones which the server
gets via broadcast. It also shows all capabilities of the broadcasted
printers as they were local. And for that no external name service or
file like /etc/printers.conf is needed. To make it as transparent as
possible for end users an application linked against libpapi running on
a box with CUPS as printing system should show the same printers and
options as an application directly linked against libcups and this
should be achieved without any change on the CUPS configuration, the
CUPS daemon or library code and without any extra name service or browse
listener daemon.

It is a nice thing to have the libpapi-dynamic which can pull in various
other PAPI libs and poll name services to serve on machines with
different spoolers running in parallel, but I think there should also be
a PAPI library which gets the full information out of CUPS. Perhaps this
PAPI library (psm-cups.so or libpapi-cups.so) is perhaps more easily
done by linking it against libcups to avoid redoing of code.

   Till