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

[Michael Sweet]

Yasumasa TORATANI wrote:
> ...
> The dataflow is as following;
> 
> [CUPS filters]-->[CUPS standard backend]<-->[bi-di plug-in]<-->[prt]
> 
>     or
>                                    +----[bi-di plug-in]--------+
>                                    |                                         |
>                                   V                                        |
> [CUPS filters]-->[CUPS standard backend]---->[prt]
> 
> Furthermore, if we make the bi-di plug-in API generic, everyone will
> be able to reuse these modules for any other printing system if they
> want.

As I've posted before, the CUPS 1.2 dataflow will include a
pipe going from the backend to the filters, so the backend can
send the backchannel data to a printer-specific printer driver
for processing (so the intelligence would be in the printer driver
and not in the backend).  Your implementation is basically making
the CUPS backend a printer driver which talks with a separate
daemon/process to communicate with the device.  This is certainly
doable, but limits the use of your driver to interfaces that the
bi-di plug-in API (instead of all devices); we wouldn't do that
for regular consumer devices, but if you have a custom interface
already (high-speed serial card/whatever) to the device, this isn't
so much of an issue...

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