Architecture astronauts take over

Posted May 23, 2012 15:01 UTC (Wed) by alexl (subscriber, #19068)
In reply to: Architecture astronauts take over by spaetz
Parent article: Announcing printerd

CUPS will not be entirely replaced. It will still be what talks to the printer, picks the right drivers, manages the installed printers, etc.

printerd is more like a session print spooler. It lets you enumerate printers, submit jobs to them, etc. If the printer was a network (ipp) printer that supports pdf, or a cloud service like Google Cloud Print then everything will run without any instance of CUPS.

However, if you're printing to a local printer, or a printer attached to a print server (on linux) then printerd will hand the pdf over to CUPS, running locally or on the server.

Tim has a nicer explanation in an earlier blog entry:
http://cyberelk.net/tim/2012/03/08/session-printing/

Architecture astronauts take over

Posted May 23, 2012 16:56 UTC (Wed) by cmccabe (guest, #60281) [Link] (3 responses)

Hi alexl,

CUPS already has support for being a print spooler. It already allows you to "enumerate printers, submit jobs to them, etc." What is printerd going to provide that CUPS does not?

Please keep in mind that another layer of software is another layer of bugs that we will all have to debug. Even the best programmers sometimes make mistakes. If there's no value add from the additional abstraction, then I would prefer to keep things simple.

I would love to see something take over from cups, but only if it provides the same features that cups provides. I'm not really interested in running the printer daemon version of "duelling banjos."

Architecture astronauts take over

Posted May 23, 2012 18:42 UTC (Wed) by alexl (subscriber, #19068) [Link] (2 responses)

I'm aware of how CUPS work. And the link I posted explains this too.
For the case of a local printer printerd would just call out to the local cups daemon just like currently, and printerd would be nothing more than a frontend for cups with an API that is nicer for async code (ever tried to write async code using libcups?).

However, if you're not using a local printer, but rather some network printer or cloud service then having to have a local system-wide print spooler is completely unnecessary, and printd would just forward the job to the spooler on the remote server, working completely in the user session.

Running in the session has some advantages besides just needing less code. It also allows the spooler to do things like authenticate to the cloud service in a normal way, as its part of the user desktop session, rather than some system service.

Anyway, Tim knows this stuff better, and he posted a new blog entry: http://cyberelk.net/tim/2012/05/23/some-benefits-of-print...

Architecture astronauts take over

Posted May 23, 2012 22:41 UTC (Wed) by cmccabe (guest, #60281) [Link]

To be honest, I really don't care about asynchronous printing. How can I say this in the most tactful way-- I care more about dusting my ceilings than I do about the fact that applications need to spawn an extra thread to print.

My printer is a USB printer. It requires a printer driver to work. A driver which, incidentally has not been updated or fixed in years, and is not officially supported by the distro. Luckily I know enough about the plumbing to know how I can get this thing to work. (Should "work" be in quotes?)

At work, there is an IPP printer which I mostly use. The time I spent setting it up in CUPS was about 5 minutes, including printing test pages and all that.

> Running in the session has some advantages besides just needing less code.
> It also allows the spooler to do things like authenticate to the cloud
> service in a normal way, as its part of the user desktop session, rather
> than some system service.

Again, I just don't care. I've never used a multi-seat Linux machine (and I've had 5 jobs where I used Linux, including one where we used it in the cloud.) I also don't see what fundamentally prevents CUPS from doing the same thing-- i.e., accepting or rejecting jobs based on the user id that submitted them.

So far, printerd has not proposed to solve any of the problems I have ever had. Of course, I'm just one user-- perhaps others will have different needs.

Architecture astronauts take over

Posted May 23, 2012 23:02 UTC (Wed) by jjs (guest, #10315) [Link]

I read his articles, and am still uncertain of the benefits. CUPS talks fine to remote printers. He admits CUPS integrates with polkit. Right now I tell my app to print, answer the various questions (# of copies, printer, etc), and off it goes. I go back to my app,and sometime later the printer prints my work (asynchronous from my viewpoint).

So other than adding another layer between the application and CUPS, what does printerd do?