It’s nearly two years since I wrote about session printing, in which the user doesn’t need to modify a locally running CUPS instance in order to print to a network printer. The main advantage of having printing running entirely in the user session is that no special privileges are needed. After all, all you need to do is send the document over the network.
So what’s the current state of play?
Recently I talked about a new print spooler under development, printerd. In that post I mentioned briefly how printerd is structured, but did not go very deeply into why or what the project is for.
Firstly, printerd is experimental and is very far from being a functional print spooler. It doesn’t yet run any filters, for instance, and has no backends of its own to transport jobs to devices. So far it is just a test of what a Linux print spooler would look like if it were written today.
There are several problems printerd aims to solve. Some of the solutions come automatically from implementing it as a polkit-enabled D-Bus system service. I mentioned one of them in the original post about printer: the fact of having an asynchronous client API. All D-Bus services can be used asynchronously thanks to the D-Bus client library. This approach means the print dialog will be able to use printerd without blocking (and without having to start another thread to use it).
For the last few weeks I’ve been working on an experimental new print spooler called printerd. It was designed in collaboration with Richard Hughes and it aims to be a modern print spooler for Linux.
It is a polkit-enabled D-Bus system service, written using the GLib object system. Although modelled on concepts from IPP (Internet Printing Protocol), printerd is not in itself an IPP server. Its only interface is D-Bus, although the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process. Having a D-Bus interface means that applications wanting to print automatically get to use printerd asynchronously.
As a design decision, the range of input formats accepted by printerd will be very limited: essentially only PDF. The existing CUPS drivers and backends will be compatible with printerd.
There isn’t much written yet aside from the basic framework and a very simple command line tool.
Feel free to take a look around: http://github.com/hughsie/printerd
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).
As I mentioned elsewhere, there are some changes ahead in CUPS 1.6. These changes are not imminent but give an indication of the direction the CUPS project is heading.
Back in 2007 CUPS became an Apple project. Now the parts that are not relevant on Mac OS are being dropped, with some of the Linux-relevant parts being gathered together in a separate project, cups-filters.