[Printing-architecture] Optimizing MicroJobTicket - JTAPI 'native' symbols - second n ote
glen.petrie at eitc.epson.com
Tue Apr 1 10:40:42 PDT 2008
Is coherence, at the level we are discussing needed or wanted? Or is what
is needed/wanted is a translation mechanism to "seamlessly move between
Coherence to me and in this context would mean consuming any job-ticket
format and outputting a common (read as coherent) job-ticket representation.
MJT ----->---->>> common job-ticket representation
XYZ JT --/
A translation mechanism says "take what I got and give me something I can
^ MJT becames a JDF
XYZ JT --/
I believe in coherence but I also believe the world only needs/wants
Therefore, the project as I proposed uses JTAPI to create the translation
service; as I believe was the originally intended. When you add the concept
of a binary (internal) job-ticket representation writer/reader you can
achieve a small degree of coherence or at least start a path to coherence.
I also designed the project to accept only a few variations of a MJT. This
is so Lars would not have to process all the possible attribute values of a
MJT (read this as IPP). He only needs to concentrate on the one in the
pre-defined MJTs and focus his development time on the core JTAPI code. I
had to scope the project as a summer project but tried to figure out how to
structure the activity so that is could continue afterwards.
Therefore, let's leave MJT as is. I actually picked MJT because I
understood it to be simplified job-ticket based on IPP and PWG content.
Isn't defining the second standard suggested below creating another
job-ticket format? If we are going to do that then I would rather spend the
time create the specification for the binary (internal) job-ticket
representation discussed above.
> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Tuesday, April 01, 2008 10:00 AM
> To: printing-architecture at lists.linux-foundation.org; Lars Uebernickel;
> Petrie, Glen; Ira McDonald
> Subject: Optimizing MicroJobTicket - JTAPI 'native' symbols
> Right after I suggested we just use MJT for any needed interprocess
> serialization of a parsed job ticket in the JTAPI Library, I thought
> "Hey, the current MJT uses IPP standard property names and values
> and a PWG namespace - duh!"
> I suggest that I revise the PWG MJT working draft to be an OP MJT
> working draft (which I need to do anyway).
> I should define a second standard JTAPI namespace for MJT, that uses
> JTAPI standard property names and values - this would let the external
> job ticket match exactly the OP canonical names from JTAPI - a very
> long-standing coherence goal that Glen has championed and I support.
> However, for use with CUPS and/or PAPI integration, support for the PWG
> IPP names in MJT is also important. Hmm...
> Comments, Glen and Lars?
> - Ira
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com
> 579 Park Place Saline, MI 48176
> PO Box 221 Grand Marais, MI 49839
More information about the Printing-architecture