[Omniprint-developer] Re: [printing-driver] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Robert L K. <rl...@al...>]

   From: Michael Sweet <mi...@ea...>
   Date: Wed, 9 Jan 2002 09:00:26 -0500

   On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote:
   > ...
   > This all really depends on what set of problems you want to solve.
   > If you look at several scenarios it will better define the components
   > that are needed and the way you could handle most of the scenarios.
   > We need to handle:
   > -  Device configuration information dynamic from the printer
   > -  Status information returned from the printer
   > -  Local configured printer
   > -  Network configured printer

   I would argue that we do not want to distinguish between a local
   and network printer.  All printers should be treated the same, and
   an application that communicates with a local print queue should be
   able to access a network print queue the same way.  Again, I'm
   harping on network transparency!

I agree with this.  I would further argue that if the behavior of the
printer differs depending upon whether it's locally connected in a
single user environment vs. remotely connected, or in a multiuser
environment, that the system violates the "principle of least
surprise".  Unless it's absolutely impossible to provide identical
semantics (which I don't believe it is here), distinguishing these two
cases will simply lead to user confusion.

   > 1. Local printer configuration and capabilities
   >
   >   The local printing (single user) scenario is fairly easily handled
   >   when utilizing IPC mechanisms.  Latency and information about the
   >   printer go away in this scenario because you don't have to worry
   >   about the 100 user scenarios.

   I would argue that even a single user will have multiple windows,
   etc. open that want to access a printer at the same time,
   especially to check the current status.

While it's true that the latency issue largely goes away in this case
(at least if the printer supports an IEEE 1284.4 packet mode, which
Epson printers do, and the driver deals with this), it's really not
clear to me why we want to special case this.

   >    Local printer status information
   >
   >   When doing local printing, the status should be immediate and any
   >   device specific protocol converter (daemon) of the data be manage
   >   the flow to and from the printer to always maintain an accurate
   >   account of the status of the job and printer state.

   The device daemon should *not* try to understand the data to/from the
   printer, nor should we expect it to track printer or job status.
   Specialization leads to bloat and all sorts of implementation problems.

Depends upon exactly what the device daemon does.  If the device
daemon actually talks to the printer, it may have to understand the
data if the printer is a winprinter (the infamous Samsung laser
printer requires reasonably correct timing for sending data).  But the
application shouldn't know about the existence of something like this,
and certainly shouldn't talk to it.

   >   - An IPC mechanism for getting dynamic information from the
   > driver and subsystem will be mandatory for licensing purposes.
   > It would likely be simpler if a singular interface could be used
   > by both an application and the renderer.

   I would argue that an IPC mechanism at the application level has
   already been defined and implemented - IPP.  Between driver and
   device, the interface to use is the pipe/socket: that abstracts
   the device IO into simple modules that can be reused for many
   drivers and devices.  The printer-specific stuff is then handled
   entirely by the printer driver, which has to be specialized...

I'd like to repeat my question to the people advocating a new
mechanism: what required capabilities does IPP lack?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton