[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