Re: User session printing
On Fri, 2012-03-09 at 08:21 -0900, Jef Spaleta wrote: > Back to the use case of a primarily single user laptop touching > multiple networks on a daily basis. For that situation is it expected > that the default print server will still be the laptop's own cup > server for networked printers? Networked printers that communicate using IPP, and which can accept PDF natively, could be used directly from the user session without needing a CUPS server, either running locally or on the network. In practice I'm not sure how many jobs IPP printers are generally able to queue -- it may only be 1. In a busy office it might be preferable to have a print server machine running CUPS, and have clients use that instead of sending jobs directly to the printers; that way jobs will get spooled. There would still need to be a locally running CUPS server if any other communication protocol is used (LPD, JetDirect, SMB/CIFS etc), or if the printer does not accept PDF. For one thing, those protocols don't allow us to detect whether PDF is accepted or not. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Fri, Mar 9, 2012 at 12:46 AM, Tim Waugh wrote: > Yes, exactly, and that is what I'm suggesting. For printing entirely in > the user session it is a case of using an alternative to using CUPS > running on the local machine, so that means: > > a) no filters or drivers; the job document is the PDF produced by the > application/print dialog > > b) no queueing; submit the job directly to the print server, and if that > fails then explain why immediately Seems reasonable. Immediate failures will be less for confusing for everyone. And it'll give frontline technical support (community and/or organizational) some ability to actually troubleshoot the failure as its happening. Back to the use case of a primarily single user laptop touching multiple networks on a daily basis. For that situation is it expected that the default print server will still be the laptop's own cup server for networked printers? Or is it expected that by default users will be configuring to talk to the printer server daemon embedded on the actual network printers without having to interact with a local cups daemon at all? I just want to be clear on what b) will look like as part of designed for flow. -jef"Fail Faster!"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Thu, 2012-03-08 at 09:52 -0900, Jef Spaleta wrote: > 2012/3/8 Miloslav Trmač : > > The lazy answer to both is "fail, or not, the same way as cups > > currently fails, or not" (in fact, could the session printing service > > simply be cups that treats the system instance as another remote > > server?). > > If we were looking for the lazy answer, we'd just not bother with queing at > all. Yes, exactly, and that is what I'm suggesting. For printing entirely in the user session it is a case of using an alternative to using CUPS running on the local machine, so that means: a) no filters or drivers; the job document is the PDF produced by the application/print dialog b) no queueing; submit the job directly to the print server, and if that fails then explain why immediately Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
2012/3/8 Miloslav Trmač : > Right... I just wanted to make sure that any potential work on user > session printing is not discouraged by adding requirements that are > not currently satisfied with the system daemon. Of course. That wasn't meant as stop energy. If those situations have a _least surprise_ with current network awareness that would be groovy. Perhaps jobs to local network addressable printers can be handled differently than global network addressable printers in terms of whether they automatically get reattempted from the que in the userspace. Barring malicious network admins ( waves) that would perhaps cut out a lot of embarrassing "holy crap my print out of those pictures from last night's party went to which printer?!?" moments of sheer panic. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Thu, Mar 8, 2012 at 7:52 PM, Jef Spaleta wrote: > 2012/3/8 Miloslav Trmač : >> The lazy answer to both is "fail, or not, the same way as cups >> currently fails, or not" (in fact, could the session printing service >> simply be cups that treats the system instance as another remote >> server?). > > If we were looking for the lazy answer, we'd just not bother with queing at > all. Right... I just wanted to make sure that any potential work on user session printing is not discouraged by adding requirements that are not currently satisfied with the system daemon. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
2012/3/8 Miloslav Trmač : > The lazy answer to both is "fail, or not, the same way as cups > currently fails, or not" (in fact, could the session printing service > simply be cups that treats the system instance as another remote > server?). If we were looking for the lazy answer, we'd just not bother with queing at all. -jef"Goes to setup is home network to blackhole and log all print requests to non-existent network printers issued from clients on the network"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Thu, Mar 8, 2012 at 7:19 PM, Jef Spaleta wrote: > 1) What if I've hopped networks since then and the print job that was > que'd was on a printer that was only visible on the original network? > > 2) What if I've hopped networks and the old network and the new > network have a printer at the same 192.168.x.x address but are > physically different printers? The lazy answer to both is "fail, or not, the same way as cups currently fails, or not" (in fact, could the session printing service simply be cups that treats the system instance as another remote server?). Ideally, I suppose, we would need a concept of "network identity", at least for wireless networks (where NetworkManager already can distinguish between networks) and perhaps even for wired networks (where at least Windows 7 tries to distinguish between them, and in some cases fails quite visibly). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Mon, Mar 5, 2012 at 8:02 AM, Bill Nottingham wrote: > Tim Waugh (twa...@redhat.com) said: >> 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. 1) What if I've hopped networks since then and the print job that was que'd was on a printer that was only visible on the original network? Answering my own questions: test the ipaddress and continue to wait if its not available 2) What if I've hopped networks and the old network and the new network have a printer at the same 192.168.x.x address but are physically different printers? I have no idea how to make sure you aren't printing to the wrong printer that is scoped with a local network address. Do we have any technical mechanism to prevent this from happening for que'd jobs that automatically try to start on re-login for personal computing that are anticipated to hop networks ? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote: > Tim Waugh (twa...@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. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
Can't we just get the policy right so that users can add queues? Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
Le Mar 6 mars 2012 14:53, Miloslav Trmač a écrit : > This requires: > * A network printer > * ... that has a 300page paper tray, so it is clearly an industrial one ̌1. The standard paper tray for even the smallest laser is usually 250 pages, they are dirt cheap and a second paper tray is not expensive http://reviews.cnet.co.uk/printers/brother-hl-2250dn-review-50004574/ Microscopic paper trays are reserved for color inkjets where you pay an arm and a leg for a microgram of bad ink. 2. Ghostscript postscript quite often confuses postscript printers and they'll happily print hundreds of pages of garbage for one bad ps page. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Tue, Mar 6, 2012 at 2:46 PM, Nils Philippsen wrote: > On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote: >> Tim Waugh (twa...@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. > > I wonder if that works with longer print jobs: > > - User: "I'll kick that one off before the weekend, it might take a > while, so that I won't disturb others." > - (User's) cupsd: queues the job in user's home, starts printing onto > the printer. > - User logs off after 15 pages of 300 are printed. > - systemd kills off all processes in user session cgroup, including > cupsd. > - User: "Aiiieh!", heads off into the weekend as he has to catch a bus, > forgets about it. > - User returns after the weekend, logs in again, cupsd picks up the > still queued print job from user's home, starts printing the remaining > 285 pages. This requires: * A network printer * ... that has a 300page paper tray, so it is clearly an industrial one * ... but does not have a separate print queue * an user that starts a print job and leaves? I don't know how much that is likely. In any case, the per-user cupsd could stay running after the user logs off until the queue is empty - then there should be no discernible difference between the system queue and per-user queue until the system reboots (when it reboots, the per-user cupsd probably wouldn't start and continue processing the job again - although that could be arranged as well). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote: > Tim Waugh (twa...@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. I wonder if that works with longer print jobs: - User: "I'll kick that one off before the weekend, it might take a while, so that I won't disturb others." - (User's) cupsd: queues the job in user's home, starts printing onto the printer. - User logs off after 15 pages of 300 are printed. - systemd kills off all processes in user session cgroup, including cupsd. - User: "Aiiieh!", heads off into the weekend as he has to catch a bus, forgets about it. - User returns after the weekend, logs in again, cupsd picks up the still queued print job from user's home, starts printing the remaining 285 pages. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
Tim Waugh (twa...@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. > Another issue is that the LPD printer protocol requires the client to > connect from a privileged port, so it won't work for that without some > extra hoops. What % of networked printers are using this protocol these days? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
User session printing
(changing the subject line since this is a bit different from the original topic) On Sun, 2012-03-04 at 00:22 +0100, Miloslav Trmač wrote: > Another way to look at this issue is - if printers were maintained > per-user (per-user, unprivileged cups daemon, per-user configuration, > per-user print queue), there would be no reason to ask for > authentication. Given that printers are so often networked nowadays > and no access to hardware is required, we might even be able to avoid > running the system-wide cups daemon at all in some cases. There would > be one less process running as root, no reason to authenticate, an > increase both in security and ease of use. [...] > Would something like this at all possible to do with cups and the > current printing design and protocols? 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? Another issue is that the LPD printer protocol requires the client to connect from a privileged port, so it won't work for that without some extra hoops. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
