[Omniprint-user] Re: Taking a step back

[Pete Z. <pz...@us...>]

      > ...
      > 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.

The above was an example of problems to solve, not all the problems or that
each of the problems should be handled in different ways.  If you don't
define what we are trying to solve we will never put code in place to
handle
those conditions.  This wasn't meant to differentiate the items.

      > 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
>   Epson printers do, and the driver deals with this), it's really not
>   clear to me why we want to special case this.

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.

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 apps.  The application will not have
access to the output device so spooling is the only real option here to
return the application to the user when multiple apps are printing.

      >    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.

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.


     >   - 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?

I don't think that we are really advocating something other than IPP.  It
may end up that way but I think we are just talking about two different
levels and communications areas of the system.

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.

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.

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.

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 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 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.




Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...