[Printing-architecture] Google Summer of Code 2008: JTAPI Library Project

Ira McDonald blueroofmusic at gmail.com
Tue Apr 1 09:48:50 PDT 2008


Hi Lars,

You've got it - works only in a single process - if the data has to be
serialized, well
that's the *purpose* of Job Ticket formats - we should NOT develop a new JTAPI
private serialization of the internal C structures - the MJT encoding
is sufficient
and structured.

My two cents,
- Ira

On Tue, Apr 1, 2008 at 12:33 PM, Lars Uebernickel
<larsuebernickel at gmx.de> wrote:
> Petrie, Glen wrote:
>  > Lars,
>  >
>  >
>  >
>  > During your design phase of the JTAPI I would like you to consider what the
>  > original intent of the JTAPI is and, what I believe it another use of the
>  > JTAPI.    The original intent is two fold (if memory service correctly).
>  > The first, and I believe the primary intent, was to have library (tools)
>  > that could create different Job-Ticket formats (JDF, MJT, proprietary-JT)
>  > from a common set of API's, objects and attributes without the
>  > user/developer having to know anything about the final job-ticket format.
>  > The second intent was that by the addition of a "front-end" module one
>  > job-ticket format could be inputted and parsed into the JTAPI common
>  > objects/attributes; then using the JTAPIs, a different job-ticket format
>  > could be generated ---- that is a job-ticket translation service.
>
>  I agree, these were the two uses I had in mind.
>
>
>  > I see the third use of the JTAPI as either a common interface or front-end
>  > translation service to an internal job-ticket object (a C data struct in
>  > this case since JTAPI is to be coded in C) representation.  That is, a
>  > developer uses JTAPI as an input portal to an internal object definition and
>  > may never create an actual JDF, MJT or proprietary-JT formatted job-ticket.
>  > In this case the job-ticket info (struct) is directly passed on to the next
>  > print processing module.   I actually see this as the big potential use of
>  > JTAPI and its associated objects/attributes definitions.
>
>  This could speed up the print process quite a bit - the job ticket need
>  only be parsed and interpreted once and could be used throughout the
>  print processing chain. But this would only work for modules in the same
>  process, right? Otherwise, the data has to be serialized in some way to
>  pipe it to the next processing module.
>
>
>  > Thus, during your design and development phase of the internal component of
>  > the JTAPI, please pay extra attention to how you design and document the
>  > internal job-ticket objects.
>
>  I will. Thanks for your ideas!
>
>    Lars
>  _______________________________________________
>  Printing-architecture mailing list
>  Printing-architecture at lists.linux-foundation.org
>  https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>



-- 
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