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

* [Printing-architecture] CUPS 3.x: Printing via D-Bus
@ 2022-04-26 16:56 Till Kamppeter
  2022-04-27 12:21 ` Michael Sweet
  0 siblings, 1 reply; 3+ messages in thread
From: Till Kamppeter @ 2022-04-26 16:56 UTC (permalink / raw)
  To: Michael Sweet, Open Printing

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

^ permalink raw reply	[flat|nested] 3+ messages in thread