There has been a discussion on the Fedora devel mailing list recently about user session printing: why that might be useful, and in what circumstances it makes sense.
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).
A little about Google Cloud Print: this is a service that allows you to register your local printers with their service, and share those printers with other people. It currently works as part of Chrome: it maintains an XMPP connection to Google so that incoming jobs can be received and passed on to the local CUPS queue. For printing jobs to it, it is simply an authenticated web service.
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
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.