Re: [Printing-architecture] CUPS 3.x: Printing via D-Bus

Michael Sweet <[email protected]> Wed, 27 Apr 2022 08:21:51 -0400
Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>
Till,

My thoughts on the DBUS interface (and any future XPC interface, should Apple adopt our work) is that it should expose the same IPP operations, attributes, and values as are available over HTTP.

The local spooler needs to:

1. Manage a dynamic list of print destinations (DNS-SD, mDNS, local configuration profiles, Printer Applications, etc.)
2. Do queries for state/configuration/capabilities for a given destination, with some level of caching
3. Manage a dynamic list of queued jobs for those destinations, with the usual Create/Cancel/Reprint-Job functionality
4. Do minimal conversion/transform of document data for the destination (text, image, and PDF to PDF/raster)
5. Report any printer/job errors with possible actions (cancel, retry, etc.)
6. Handle any authentication challenges when sending jobs to destinations


> On Apr 26, 2022, at 12:56 PM, Till Kamppeter <[email protected]> wrote:
> 
> Hi,
> 
> I have looked through the CUPS 3.x planning and hit into the following feature:
> 
> Printing via D-Bus
> ------------------
> 
> In the local CUPS server it is planned to provide, in addition to the usual Unix domain socket, a D-Bus interface to receive requests from the client.
> 
> This is not a new idea but before it was not thought out to be done in the CUPS daemon itself but in separate utilities.
> 
> Back in 2006, on the first OpenPrinting Summit in Atlanta, Georgia we raised the idea of a Common Print Dialog and I started its implementation via the Google Summer of Code 2008, the first one ever I have participated in, I suggested my students to let the GUI applications not call the print dialog via direct library calls but by a D-Bus interface so that the desktop environment provides the dialog and so all applications appear with the same print dialog, if you use GNOME, all applications show the GTK dialog, also the Qt ones.
> 
> We did not succeed to complete this due to lack of man power for the coding.
> 
> Recently, I investigated how Flatpak handles applications with print functionality, and what they do is exactly this concept, not only for printing, but also for "Open", "Save as", ... dialogs. This way the system's dialog are used by the sandboxed application and through these the application has access to system resources like file systems and printers. I do not know whether they came to this idea by themselves or whether they picked up my idea of the Common Print Dialog, extending it to the other dialogs. They never talked with me.
> 
> Independent of all this, back in 2017, when I did not know anything about Flatpak (did it exist already that time?) Aveek Basu remembered me to the Common Print Dialog project and whether we should revive it.
> 
> But I came to the conclusion to not put a D-Bus interface between application and print dialog but between print dialog and print technology (CUPS, print-to-file, cloud print services, ...) so having the dialog being a frontend and talking to backends, one for each print technology, and let the author/maintainer/provider of each print technology also maintain his backend.
> 
> This I have called the Common Print Dialog Backends (CPDB) then:
> 
> https://linuxplumbersconf.org/event/11/contributions/1028/attachments/762/1433/Common-Print-Dialog-Backends.pdf
> 
> Good part of it is already implemented in GSoC 2017 and following.
> 
> This D-Bus interface does the standard print activity:
> 
> - List the available printers
> - List capabilities and user-settable options for a selected printer
> - Send a job to a selected printer, with option settings
> - List the jobs
> 
> What my imagination is for Michael's idea of a D-Bus interface to print on a local CUPS server is exactly this functionality. Therefore I think that we SHOULD NOT develop a new D-Bus interface for CUPS and then have our CUPS CPDB backend on its front side receive print requests from the print dialog via one D-Bus protocol (CPDB), convert the request to another D-Bus protocol (CUPS 3.x) and pass it on to CUPS, but instead, we right away take the CPDB D-Bus interface protocol and implement it in the local CUPS server, so that we do not need a separate CPDB backend for CUPS any more.
> 
> Note that CPDB is not actuall;y used in the wild yet, so we can do any change on it to make it better suit CUPS if needed. Nothing is hammered in stone yet.
> 
> WDYT?
> 
>   Till
> 

________________________
Michael Sweet
signature.asc (application/pgp-signature, 833 B)