[printing-discuss] Taking a step back

[Raph Levien]

I'd like to take a step back for a moment and take a look at the
current state of ipc protocols for hooking rasterizers to drivers.

First, I realize that I'm responsible to a large part for the current
situation. I essentially created a fork by starting my own IJS code
base, even though IBM had a working prototype and reasonable proposal
for their version of the protocol. I also made matters worse by not
being very responsive to subsequent queries from the Omni group. For
this, I apologize. It's not hard to see why IBM has also chosen to
continue pressing forward.

Now let's try to sort it out.

Just how many protocols do we need?
===================================

As it stands, the latest PDC and IJS proposals overlap quite a bit.
Deploying both would probably cause a lot of confusion about which one
to use. This kind of confusion usually leads to usability problems,
often quite serious. I think it's worth avoiding.

I think we need to take a look at how IPP fits into this, as well.  I
seriously considered just implementing IPP. The only reason I chose to
hand roll my own protocol was to make it simpler and more lightweight.
Given that PDC seems to be much more willing to take on complexity, I
think it's worth asking again: why implement yet another protocol?
IPP had a lot of good work put into it, and also sports a widely used
open source implementation: CUPS.

Whatever protocol is adopted for rasterizer <-> printer driver
communications, it will almost certainly need to gateway to IPP.
Using IPP natively obviously makes this problem a lot simpler.

Obviously, there would need to be a fair amount of work done to tweak
IPP to work well for inkjet applications, particularly nailing down
the raster format. But, to me, it makes more sense to just define that
within IPP than to reinvent the entire rest of the spec around it.

That said, I still believe there's a valid ecological niche for
something like IJS. Implementing an IPP server (or its moral
equivalent) in a printer driver is not trivial. Implementing IJS is.

Other problems that need to be solved
=====================================

IJS is very narrowly focussed, and explicitly does not try to solve
all the problems of the world. It's not that I believe those other
problems to be uninteresting. Rather, I believe that solving them
_outside_ the printer driver ipc protocol will make life much
easier for authors of printer drivers, as well as being a better
solution in the end.

In particular, we need:

1) A way to map device ID (usually autosensed) to a driver capable
   of talking to the device. This implies a database of some kind.
   It would be even better if the packaging standards for printer
   drivers automatically added entries into this database when
   the printer driver package is installed.

2) Enough pieces for applications to put together a UI for selecting
   the printer and its usefully settable options. Of course, building
   UI's is hard. For one, there are at least four interesting free
   desktop platforms (Gnome, KDE, Mozilla, and StarOffice) and a
   couple more non-free. Then, you have to deal with
   internationalization. On Windows, the printer driver experience
   also includes graphical icons and depictions of the printer.

3) Most of the time, you will want a spooler of some kind. If such
   a spooler "owns" a local printer, then one would also expect it
   to be able to multiplex connections from various apps.

I don't believe that the driver ipc protocol is the best place to
solve any of these problems. If you have a database that knows about
all your printer models, then it's reasonable to expect it also to
know about internationalized strings and possibly other ui
niceties. Getting the rasterizer involved doesn't make that much sense
to me.

Similarly, if you've got a spooler doing multiplexing, then the print
driver itself need not do this. Thus, there's no need for this code to
be multithreaded (or the select-based equivalent). The driver also
need not be responsible for access control. This makes life _quite_ a
bit easier for driver authors, and it's also likelier for access
control policies to be consistent.

This is why I consider many of the "features" of PDC over IJS to be
a _bad_ thing.

Process
=======

There are some pretty big differences in process between the PDC and
IJS efforts. It's worth acknowledging this, I think. I percieve that
PDC is somewhat vaguely defined, with a nontrivial risk of ending up
as yet another "design by committee" interface. Conversely, I'm sure
others percieve IJS as being designed by a cranky eccentric who is
only able to put time into it sporadically. There's no doubt truth
in both views :)

That said, IJS _is_ farther along. There's a reference implementation
in C, released under an MIT license. It's been integrated into two
drivers, by two different authors. There's a pretty reasonable client
implementation in Ghostscript, without a dependence on the Omni
codebase. There's now a reasonable draft spec. Because the original
goals of IJS are so tightly defined, it's possible to say with good
confidence that IJS currently comes very close to meeting these goals.

Many of the differences between the IJS and PDC are fairly trivial,
yet certainly great enough that the two protocols are not compatible.
I think it would be great to resolve these trivial differences.

I realize it's a bit unfair to ask the Omni group to play by my
process (especially since I'm the one most responsible for the current
fork), but I would like to ask them to seriously consider adopting the
IJS wire protocol as the basis of their driver IPC effort. In
particular, I would like Omni IPC servers to work with IJS clients, at
least in terms of basic printing functionality.

In return, I promise to do my best to be responsive to the needs of
the Omni group. I would like to start by making sure the IJS extension
mechanism is robust enough to handle Omni extensions. The current 0.30
spec contains a parameter namespace prefix mechanism that gives Omni
their own chunk of namespace to play with. I'd also be very open to a
similar extension mechanism for commands.

I'd be perfectly willing to adopt PDC if it were further along.
However, in the short term, I think it's better for users to have a
working solution based on IJS. If we're able to cooperate, then I
think IJS can also serve the long term needs of Linux printing
well. I'm willing to give it a shot, anyway.

I think a very good next step is to agree on a set of problems that
the current IJS proposal does solve, with some consensus that the
rasterizer <-> printer driver is the best place to solve these
problems. Then, we can try to figure out how to fix these problems,
without compromising the integrity of the original IJS vision.

Sound reasonable?

Take care,

Raph