[Printing-architecture] Have I misunderstood what Bi-di was about

Petrie, Glen glen.petrie at eitc.epson.com
Wed Mar 17 08:47:52 PST 2004


All,

 

I have read the Bi-di specification (better late than never) and I was
surprised at its overall function.   I thought Bi-di was only a
bi-directional communication API but not encompassing status monitoring API.
Although status monitoring requires bi-di communication, I thought the Bi-di
API was going to be more generic in that is would provide basic bi-direction
communication to any portal for any kind of data a
print-service/application/driver wanted to send/receive; for example, print
data, printer commands and, of course, status monitoring data/control.
Some printer drivers send/receive information that is not status-monitoring
data; how does this data get back to calling
print-service/application/driver?  Remember FSG specification cover the
print domain of Embedded-Mobile, Desktop/Home, Office/Network and
Production; show I doubt the only bi-di information is status monitoring
information.   I had assumed the Bi-di API would not be aware of the type of
data being sent/received but only acts as a bi-directional channel
(controller) so that a print-service/application/driver would not have to
know the physical or logical interface controls - it would only have to know
the Bi-di API - that is, a single communication interface API.

 

I thought the bi-di API would be derived by looking at 1284.4 and other
communication protocols and determining a top level API.  Example, 1284.4
requires a command, control and data channels.  We can assume other
protocols require similar channels.   So, should the generic Bi-di API have
that level of detailed control?

 

Someone hinted that each company may write their own proprietary Bi-di
implementation.  I would propose that there should be only one Bi-di
implementation that everyone can use.  The "generic" Bi-di communication API
would have not need proprietary code.  All proprietary code would be in the
print-service/application/driver where the data is understood.  Also the
Bi-di implementation should be at the same conceptual level as a spooler;
that is, it is not forked (spawned) by separate
print-services/applications/drivers but instead there is a single Bi-di
implementation controlling all I/O portals in the system.   I have not
thought this through so this idea could be reconsidered if conflicts for the
same physical/logical I/O portals can be resolved by separate forked
processes - I need to think about this more.

 

I guess I saw a different architectural model for Bi-di.  Perhaps this can
be discussed at the Japan-US meeting.

 

I think the current Bi-di specification is great but should be renamed as
the "Status-Monitor API".   This means we have to still write the basic
Bi-di API (which would/could be very similar to the "status-monitoring" one
but different as discussed in this note.)

 

I have some other concerns and I will list them here.

 

1.	It appears they have configured the API to only be a DLL.   If Bi-di
can be integrated (compiled) with other code we need a static library
possibility. 
2.	The information transfer uses XML.   Although this is an OK
technique for desktop and higher printing models, it is a big memory burden
for IA's.  I suggest that the XML interface should not be mandatory and
there should a "flag" to be able to send data in a more compressed (numeric)
format. 
3.	Like the job-ticket API, we should have function names begin with
fsg_sm_<foo> (fsg status monitoring) to ensure isolation from other
libraries.  The name "bidi" is probably used a lot in generic bi-di
libraries. 
4.	The nomenclature "job" (startjob, endjob, canceljob) is used
throughout.  This give the impression of "print job" and that control of the
"job" is through this module.   I believe the
print-service/application/driver should have "job" control API's not Bi-di.
I suggest the use of startSM, endSM and cancelSM. 

 

 

 

Rgds, 
Glen W. Petrie 
Epson Imaging Technology Center 
150 River Oaks Parkway, Suite 200 
San Jose, CA, 95134 
Voice: 408.576.4131  Fax: 408.474.0511 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20040317/299960e0/attachment.htm


More information about the Printing-architecture mailing list