Re: [Printing-architecture] Bi-di plug-in functionarities

[Michael Sweet <mike@easysw.com>]

Yasumasa TORATANI wrote:
> ...
> Yes, and I suppose it might be better, for instance,  in case of
> the printing data being blocked due to the buffer full or some
> error, such as no paper, while the driver writes the printing
> data into the pipe. I suppose the driver can't read the printer
> info from the backchannel under the single process when it's
> blocked, but the driver doesn't have to read any printer info
> from the backchannel pipe with another process or thread of
> the driver, since the printer info which affects the printer data
> generation should be obtained once before each printing, and
> probably, printer error and other info should be obtained by
> another process separately.

Actually, a driver can use select() to determine when it is
"safe" to write a buffer of data and when there is backchannel
data available, so threading is not needed.  Also, threading
can introduce performance and portability issues on some
platforms, and isn't always the correct solution under UNIX.
(unfortunately, threads are the only way to implement some
things under Windows...)

> ...
> So, one process for generating and writing the printing data,
> and another process for reading the printer status is the point.

That is one possible implementation, and it is used for the
current EPSON and Canon backends for the GIMP-print project to
provide ink level information to the user.

Again, it isn't the only possible implementation, and CUPS can
support any kind of backend/driver architecture.  The *optimal*
one from the CUPS standpoint is one where the driver handles
the encoding/decoding of printer data, and the backend handles
the communications with the printer.

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