User session printing

[Tim Waugh]

On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote:
> Tim Waugh (twaugh at redhat.com) said: 
> > For things like cloud printing, where the print server is a hosted
> > service somewhere out in the Internet, I think the applications should
> > be talking directly to it (via the print dialog).
> > 
> > For a plain network printer, where the printer might not be able to
> > accept the job while it's busy processing others, you might have to
> > queue the job and retry it later.  So if you are doing that as a user
> > process, how should that work when you log out, and when the machine is
> > restarted?
> 
> It waits until you log in again.

Where I can see it can make some sense to have printing entirely in the
user session is for PDF printing to smart services hosted elsewhere:
e.g. the office CUPS server, or Google Cloud Print.  Applications
produce PDF, so for printing to these types of service there is nothing
to do but send the PDF (along with any print options).

I've written up some thoughts about it, with a diagram, here:
  http://cyberelk.net/tim/2012/03/08/session-printing/

Here's the text:

The GTK print dialog supports multiple print backends, and currently
'cups' is the one we use for printing.  This communicates with the
locally-running cupsd.

Printing is more than simply getting capabilities and submitting jobs
though: we also need to monitor the status of submitted jobs, and
perform actions on those jobs such as pause, resume, and cancel.

Currently job status monitoring is performed in gsd-printer, which
displays notifications when a job has completed etc, and job management
actions are implemented in the "Printers" panel of the Systems Settings
application.

Adding support for printing to PDF-capable print services directly from
the session could be implemented as follows.

A new session service for printing could be created, providing methods
for obtaining a list of printers, explicitly adding/removing printers,
and with properties for finding out the current state of each printer
and whether it is reporting problems.  It could also provide methods for
retrieving the list of jobs for each printer, performing actions on
those jobs, and have properties for the state of each job.

This service could have plug-ins for dealing with the locally-running
cupsd; with CUPS/IPP servers on the network; and with Google Cloud
Print.

For the "network IPP" plug-in, it could discover available CUPS (and IPP
Everywhere) queues using Avahi, and show in the list of printers only
those queues that handle PDF.  Additionally, the print dialog could
allow IPP print servers to be added by hostname (for CUPS) or URI (for
network printers which speak IPP and handle PDF).

For the "cloudprint" plug-in, it could interrogate the Google Cloud
Print server to determine the list of available queues. (The "Online
Accounts/Google" part of System Settings knows how to log in.)

For job status feedback, gsd-printer could instead query the new
service. (Or perhaps the service would be implemented in gsd-printer?)

For job management, the printer panel in System Settings could perform
actions through the new service.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120308/3e33707f/attachment.sig>