[Printing-architecture] Optimizing MicroJobTicket - JTAPI 'native' symbols - second n ote

Ira McDonald blueroofmusic at gmail.com
Tue Apr 1 12:08:03 PDT 2008


Hi Glen,

I strongly disapprove of externally storing a so-called binary job ticket
format - fixed-size binary encodings are fragile (across versions) and
don't accomodate multi-valued properties at all.

Fine - we'll keep MJT using IPP names (it uses EXACTLY IPP names,
as are used in the serialization/deserialization functions in the PAPI
interface).

Cheers,
- Ira

On Tue, Apr 1, 2008 at 1:40 PM, Petrie, Glen <glen.petrie at eitc.epson.com> wrote:
> Ira,
>
>  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
>  job-ticket representation"?
>
>  Coherence to me and in this context would mean consuming any job-ticket
>  format and outputting a common (read as coherent) job-ticket representation.
>
>
>           JDF -----\
>                    \
>           MJT ----->---->>> common job-ticket representation
>                    /
>           XYZ JT --/
>
>  A translation mechanism says "take what I got and give me something I can
>  use".
>
>           JDF <<<<<<<<
>                       ^  MJT becames a JDF
>           MJT >>>>>>>>^
>
>           XYZ JT --/
>
>
>  I believe in coherence but I also believe the world only needs/wants
>  translation.
>
>  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.
>
>  gwp
>
>  p.s.
>
>  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.
>
>  gwp
>
>  > -----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
>  >
>  > Hi,
>  >
>  > 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?
>  >
>  > Cheers,
>  > - Ira
>  >
>  > --
>  > Ira McDonald (Musician / Software Architect)
>  > Chair - Linux Foundation Open Printing WG
>  > Blue Roof Music/High North Inc
>  > email: blueroofmusic at gmail.com
>  > winter:
>  >  579 Park Place Saline, MI 48176
>  >  734-944-0094
>  > summer:
>  >  PO Box 221 Grand Marais, MI 49839
>  >  906-494-2434
>



-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
 579 Park Place Saline, MI 48176
 734-944-0094
summer:
 PO Box 221 Grand Marais, MI 49839
 906-494-2434


More information about the Printing-architecture mailing list