[Omniprint-user] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Thursday 10 January 2002 03:27 pm, Pete Zannucci wrote:
> ...
> The point here was to explain that you don't need the caching
> mechanisms in place for having non-current information about the
> printer at a particular time.  Only when the printer can't return
> real-time information (in the middle of processing data) will the
> query information of the device need to be pulled from a cache.
> At that point in time, everything will work the same between a
> multi-user printer and a single user.  There isn't any difference
> except to make sure both cases can be handled in the same fashion.

Without caching you are going to run very, very slowly with
multiple users/processes asking for printer status.  Also, state
information queries can be very time consuming on some printers,
due to the interface, amount of information, or protocol(s) being
used.

Also, many printers offer a "continuous update" mode that a
driver can use to get status/configuration updates *when they
happen*, instead of polling all the time.  This further improves
performance because the monitor only updates the status/config
info as needed, rather than rebuilding that data at regular
intervals, on-demand, or both.

*My* point is that you *do* need a caching mechanism in place;
it may not be used all the time, but it *will* be used.

> I would also state with most printers, you still will only have one
> process at a time accessing them so the item about multiple windows
> should go away. The spool system should be the process of choice
> because with most printers, you can't print to them from multiple

Repeat after me: "Applications do not directly communicate with the
printer device."  Applications (and even the spooler, if you make the
device monitor a separate daemon) communicate with an intermediary
which manages access to the printer device.

In the normal course of events, you may have several (or thousands)
of processes/users requesting the current status of the printer.
This is one of the reasons that a certain very popular Windows
file/printer sharing program (SAMBA) has to cache all of the printer
and job status information to keep up.

Under UNIX/Linux today, few applications actually know enough to
communicate with the printing system to keep track of the current
printer and job information.  In the future, thanks to GNOME and KDE,
many more applications will be "printer-aware" and will be asking
for things like "what is your current status", or "what is the status
of the job I just printed for this user?".

What does this mean?  Well, for one thing we need to cache the state
information.  We also need to integrate state/configuration reporting
with the printing system, so that applications have a single interface
for printing.  This interface will likely be abstracted to support
multiple printing environments (e.g. KDEprint).

> ...
> This was to bring up a point that a separate process could track that
> data to and from the printer.  The management of that data via that
> process would be beneficial because the associated code that is run
> by that process will know the specifics of the datastream and when it
> can query, abort, send additional info. etc. to the printer.
>
> If you have two printers that the protocol is the same, why re-write
> the code that manages the protocol (bidirectional send, receive,
> abort, restart, etc) code into each driver.  The individual protocol
> code that can be shared on a grouping of printers therefore written
> once, tested once, and plugged in along with its sister printer
> driver.

Your first paragraph conflicts with the second.  You can't write a
general-purpose device interface (say, for IEEE-1284 packet mode)
that can handle aborting a job cleanly by "managing the print data",
unless you have the driver tell the device interface what each piece
of data is.  You might be able to define a subset of devices for
which this would work, but doing it in a general way is very, very
difficult.

In CUPS we use pipes between the driver/filter processes and the
backend (device interface) that communicates with the printer.
CUPS 1.2 adds the "backchannel" pipe that allows bidirectional
comm with the printer through the backend which handles the
device-specific communication stuff.  Both the driver/filter
and backend processes can communicate information back to
the scheduler which is provided to the client(s) that need
it.  If a job is cancelled, the printer driver is responsible
for sending any required "cleanup" data to the backend - this
will make sure that the current page is ejected, the printer
is reset, and so forth.

The point of the last paragraph is to show that it *is* possible
to support device interface/backend software for multiple devices,
or to substitute device interfaces, without having to change the
printer driver or add special handling code to the device interface.

> ...
> From a printing application perspective, I would not want to have to
> code IPP into it.  I would expect the appropriate subsystems to
> handle the management of this for me.  I would expect nice query,
> set, page, job, and drawing commands to be all I would worry about. 
> The system APIs I utilize should do all the management and how we
> talk to the printer from a system perspective should be nebulous.
> printer is.

I believe that a lot of this is already available from the KDE and
GNOME folks (for the general interface), and is provided specifically
in the CUPS API for CUPS.

> We are still grappling with the issues of renderer and driver
> interface in these groups.  The licensing issue is very real and that
> is why it is a hot button for a number of people.  Vendors would
> rather not have to open source their intellectual property because
> they have to run their drivers in the same process as open source
> licensed code.

Lets be honest - Ghostscript is the stumbling block, as most print
files in UNIX are PostScript.  Everything else is available in many
forms and under many licenses, but Ghostscript is only available as
GPL or AFPL.

Putting a generic raster interface into Ghostscript is not new -
we've been doing it since 1993 - and it works very well.  The
generic interface bypasses those licensing issues nicely.

> IPP is typical for use with communications between systems and
> systems/printers.  This does not address the fact of how an
> application talks to a driver or finds out information about the
> capabilities of the subsystem and driver combination (fonts and other
> things that can be lumped under system).  What I am pointing out is
> additional things that should be in place.

Actually, IPP *does* address those things in several of the more
recent extension proposals in the PWG.  I *strongly* urge you to
look at the PWG web site (http://www.pwg.org/ipp/) or talk with
some of the people in IBM doing work on IPP...

> What I was attempting to point out is that we need to define
> interfaces for standardization and to be able to allow extension.  We
> shouldn't be tied to the past with things such as PPDs or munging

PPDs are still the ONLY common printer description format that is
available.  They also have the advantage of limiting the amount of
special-case stuff you need (XML for Printer Driver ABC, PPD for
PostScript Printer XYZ, etc.) just to support printing.

> them so that we now become incompatible with applications that might
> not know how to parse the data.  An API needs to be defined with data

If you do it right, any compliant PPD parser will ignore the extra
attributes/comments.

> structures, possibly XML, to isolate the application from having to
> do the tedious work such as parsing information that may need to be
> changed in the future. Methods and managing should be crisply defined
> for the application via an API for capabilities support.

The PWG (again) has a working group developing a common XML format for
printer description information, which may be adopted widely enough
to be useful.

That said, any successful replacement for PPD will have to support
a superset of what PPD does, and allow for automated conversion from
PPD to XML (and perhaps back to PPD)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com