On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote: > Tim Waugh (twaugh@xxxxxxxxxx) 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. */
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel