[Printing-architecture] Re: [printing-announce] Open Printing activities in Japan

[Printing-architecture] Re: [printing-announce] Open Printing activities in Japan

[Pete Zannucci]

Michael wrote:

> Keep in mind that the current CUPS 1.2 back-channel support (which
> provides bidirectional communication with interfaces and devices
> that support it) is potentially incompatible with the architecture
> that Peter has proposed, and of course there are the security
> issues to deal with (arbitrary applications should not be able
> to communicate directly with printers.)

Michael,

What type of support do you have for bi-directional communications?
Does it handle the different protocols from each of the different
vendors since they all provide information in different ways.

The diagram I put together isn't cast in concrete but it did provide
a way for each vendor to provide specific protocol support through
a defined print system interface from a module that knows the specifics
of their individulal protocols.  If the layering isn't what is needed
and we can actually make one generic interface for all that is fine by me.



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) pzaan@us.ibm.com

Re: [Printing-architecture] Re: [printing-announce] Open Printing activities in Japan

[Mike Sweet]

Pete Zannucci wrote:
> ...
> What type of support do you have for bi-directional communications?
> Does it handle the different protocols from each of the different
> vendors since they all provide information in different ways.

CUPS 1.2 provides two pipes - one that goes forward to the backend
and one that comes back from the backend.  The backend sends data
from the filters to the printer, and any printer data back to the
filters over the "back" pipe.  Here is a simple ASCII diagram for
a typical PostScript print job to an HP PCL printer:

          +<===========+<============+<===========+
       pstops----->pstoraster--->rastertohp--->backend

Each of the "forward" pipes (stdout) goes to the next filter in
the chain until the data gets to the backend.  The "back" pipe
sends backchannel data as-is to *all* of the filters; typically
only the last filter (the printer driver) is involved.

The CUPS API has two new functions: cupsBackChannelRead() and
cupsBackChannelWrite() that implement read and write of the
pipe with timeouts, so that drivers that want to try bidi can
do so without hanging on a non-bidi interface, and similarly
for a backend to write backchannel data to filters that aren't
expecting it.

> The diagram I put together isn't cast in concrete but it did provide
> a way for each vendor to provide specific protocol support through
> a defined print system interface from a module that knows the specifics
> of their individulal protocols.  If the layering isn't what is needed
> and we can actually make one generic interface for all that is fine by me.

IIRC, the only question in my mind was how that interface would
work with the CUPS one, which is managed by the scheduler and
limits bidi communications to "registered" filter programs.  Your
diagram includes communications with UIs and other programs, which
poses many security and implementation issues which need to be
addressed - security because you don't want to provide unrestricted
access to the printer directly (aside from potentially messing the
printer up, it also allows the user to bypass accounting and other
access limits that might be in place), and implementation because
whatever interface you come up with needs to be network and interface
transparent.

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