[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