Don,
You've asked for opinions, right? ;-)
As software developers, Underscore can really only comment on the
"system side" of your proposal, so here's some questions & comments:
> Here's the single chart I presented:
>> [...]
>> - Firmware
> + Interfaces
> + APIs
> + Memory Map
Does the "APIs" item above refer to system-level API definitions,
such as C language bindings, etc? Or are you refering to APIs to
be used in embedded systems? To really make this idea fly (IMHO),
APIs must be defined for the "driver" developers. Moreover, a
standard library must be universally available so that pervasive
system-level support can be accomplished. (This approach has
always been a key aspect of the SENSE project.)
> * Why
> - Simplify task for non-printer vendor developers
> - Leverage investments of non-printer vendor developers
> - Provide wider variety of solutions for more brands
> of printers
How does this effort simplify the tasks for the non-printer vendor
developers? Similarly, how does this leverage investments by those
same vendors? (Sorry, I wasn't at the meeting, so these might sound
like dumb questions.)
Is the notion that this effort would "provide wider variety of solutions"
really valid? Considering the opposition stated by Bill Wagner, what are
the compelling market reasons to pursue this idea?
Please note that I am not against this idea, but rather am trying to
understand the business reasons for pursuing the concept.
> Many of the printer vendors at the meeting expressed an
> interest in investigating this type of work including
> Lexmark, Kyocera, Canon, IBM, etc. Intel's print server
> group was present and also expressed interest.
How does this compare/contrast with the 1284.1 (TIPSI) work?
Is it complementary or competitive?
...jay