[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)
Daniel Dressler
danieru.dressler at gmail.com
Mon Apr 2 21:26:30 UTC 2012
To continue my last email I wanted to say that I would like it if Glen
continued to be my mentor. My biggest concern is about code quality and I
think he can provide the criticism and code review I need to improve.
What exactly is the issue with implementing a micro job ticket backend? It
was my understanding that MJT would be a simple job ticket format and thus
a good one to implement as an example/development backend. Is there a
reason we might need to alter the MJT standard?
Daniel
2012年4月2日11:37 Daniel Dressler <danieru.dressler at gmail.com>:
> Sorry Glen and everyone, I forgot to reply-all, here is the email I sent
> an hour ago which only glen received:
>
>
> Thank you Glen and Ira for having this discussion its been helpful for me
> and my understanding of jtapi.
>
> My original understanding of jtapi was I think closer to ira's. That is to
> say that producing and consuming a job ticket would be the primary use
> cases driving jtapi development. A transformation server would then be a
> bonus feature once we have enough well tested producing/consuming backend
> plugins.
>
> I think a scenario where programmers roll their own implementation would
> be very suboptimal. It would require any programmer who wants to produce a
> job ticket to learn the standard. The wealth of independent implementations
> would leave massive room for bugs.
>
> By concentrating the implementation effort into jtapi we get a library
> that will handle all the odd cases for all job ticekts for programmers with
> less effort on their part than it would take to produce even the simplest
> job ticket. This should encourage job ticket adoption and be a win for
> productivity.
>
> Sorry I have more to say but it'll have to wait until after my classes.
>
> Daniel
>
> 2012年4月2日11:33 Petrie, Glen <glen.petrie at eitc.epson.com>:
>
> ** ** ** ** ** ** **
>>
>> Ok, we will proceed with Ira’s and Daniel’s understanding. We make a
>> transform service another day.****
>>
>> ** **
>>
>> Glen****
>>
>> ** **
>>
>> ** **
>> ------------------------------
>>
>> *From:* Daniel Dressler [mailto:danieru.dressler at gmail.com]
>> *Sent:* Monday, April 02, 2012 9:46 AM
>> *To:* Petrie, Glen
>>
>> *Subject:* Re: [Printing-architecture] [Printing-summit] OPS
>> Preparationminutes (28 March 2012)
>> ****
>>
>> ** **
>>
>> Thank you Glen and Ira for having this discussion its been helpful for me
>> and my understanding of jtapi.
>>
>> My original understanding of jtapi was I think closer to ira's. That is
>> to say that producing and consuming a job ticket would be the primary use
>> cases driving jtapi development. A transformation server would then be a
>> bonus feature once we have enough well tested producing/consuming backend
>> plugins.
>>
>> I think a scenario where programmers roll their own implementation would
>> be very suboptimal. It would require any programmer who wants to produce a
>> job ticket to learn the standard. The wealth of independent implementations
>> would leave massive room for bugs.
>>
>> By concentrating the implementation effort into jtapi we get a library
>> that will handle all the odd cases for all job ticekts for programmers with
>> less effort on their part than it would take to produce even the simplest
>> job ticket. This should encourage job ticket adoption and be a win for
>> productivity.
>>
>> Sorry I have more to say but it'll have to wait until after my classes.
>>
>> Daniel
>>
>> ****
>>
>> 2012年4月2日9:57 Petrie, Glen <glen.petrie at eitc.epson.com>:****
>>
>> Wow! I have a different scenario.****
>>
>> ****
>>
>> I see generation of a Print Job Ticket by a Print Client as a very simple
>> process. Using C-Code as an example; it is nothing more that a collection
>> of canned “printf” statement were the argument are the Print Intent values
>> expressed in the specific Print Job Ticket “language”. The Print Client
>> only wants to output one Print Job Ticket format, not one of several. ***
>> *
>>
>> ****
>>
>> I see parsing Print Job Ticket by a Print Service as an equally simple
>> process; although there is a lot of content/data checking. The Print
>> Service only wants to accept one Print Job Ticket format, not one of
>> several.****
>>
>> ****
>>
>> The difficult part is when the Print Client Print Job Ticket format does
>> not match the Print Service Print Job Ticket format – an impedance
>> mismatch; thus, JTAPI, provides the impedance matching or a transform
>> service. ****
>>
>> ****
>>
>> What you are outlining implies that a Print Client or Print Service
>> internally would need to use a set of data structures and definitions that
>> supports JTAPI, where it may better for the Print Client or Print Service
>> to support the Print Job Ticket more directly. This does lead to the ever
>> pending problem of “Common”; either a Common Print Client or even a Common
>> Print Service. For a Common Print Client it implies what “Label” or “Name”
>> and what “values” should be displayed. If JTAPI definitions, values and
>> names are to be used; then, JTAPI become useful for converting any Print
>> Job Ticket to a common internal format for every one to use. I like this
>> idea.****
>>
>> ****
>>
>> The same concept applies to capabilities information which is based Print
>> Job Ticket formats/definitions. ****
>>
>> ============****
>>
>> For the GSOC the time constraint, we may only get Print Job Ticket format
>> Foo converted to an internal structure. We can try to both read and write
>> of that Print Job Ticket format. ****
>>
>> ============****
>>
>> Since there may be an issue using or modifying MJT (copyright, etc), I
>> will create a very simple MIT license Print Job Ticket format for JTAPI
>> GSOC. Again, the goal of JTAPI this year is end-to-end code with a very
>> well documented set of code that will be used as illustration of
>> implementing JTAPI. The Print Job Ticket format is not important this
>> year. Next year or in a separate project, a standardized Print Job Ticket
>> format can be instantiated. ****
>>
>> ****
>>
>> Glen****
>>
>> ****
>>
>> ****
>> ------------------------------
>>
>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
>> *Sent:* Monday, April 02, 2012 8:12 AM****
>>
>>
>> *To:* Petrie, Glen; Ira McDonald
>> *Cc:* Daniel Dressler; printing-architecture at lists.linux-foundation.org;
>> printing-summit at lists.linux-foundation.org
>> *Subject:* Re: [Printing-architecture] [Printing-summit] OPS
>> Preparationminutes (28 March 2012)****
>>
>> ****
>>
>> Hi Glen,
>>
>> I agree with you that the *3rd* use case is a Client producing
>> JDF and and PrintService converting it to PJT w/ JTAPI.
>>
>> But the other two use cases (I think the dominant ones)
>> don't involve ANY conversion:
>>
>> (1) Client builds an abstract job ticket using JTAPI and says
>> write it out to a given format.
>>
>> (2) PrintService accepts that concrete job ticket and parses
>> it w/ JTAPI and uses the JTAPI parsed attributes as input
>> to the Scheduler and Interpreter subunits to process the
>> job.
>>
>> Your 3rd use case of conversion of formats can't be
>> demonstrated without at least 2 backends - it's harder,
>> not simpler.
>>
>> For all I care there's a reference only backend that writes
>> out (and reads in/parses) only an internal C struct form
>> of a job ticket.
>>
>> Or writes out MJT, but it That intellectual property and
>> status issues - the spec is PWG copyrighted and it's
>> a whitepaper, not an approved PWG project (that is, we
>> CANNOT modify MJT w/out PWG permission).
>>
>> WDYT?
>>
>> Cheers,
>> - Ira
>>
>>
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG IPP WG
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - TCG Embedded Systems Hardcopy SG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music/High North Inc
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> mailto: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****
>>
>> ** **
>>
>> 2012/4/2 Petrie, Glen <glen.petrie at eitc.epson.com>****
>>
>> Ira,****
>>
>> ****
>>
>> I must admit to being totally confused. I always under the impression
>> that JTAPI was a classic definition of a transform service and not just a
>> job ticket interpreter for a Print Service. I thought a transform
>> service accepts one document format and product a different document
>> format; which is what I thought JTAPI did. Example, accept a JDF job
>> ticket and produce a PWG job ticket. ****
>>
>> ****
>>
>> What you describe below is what I would call it an interpreter and,
>> maybe, that you have considered JTAPI to be. Then, at least to me, the
>> existing JTAPI may not be what is needed. What is needed is a generic JDF
>> interpreter, a PWG:PJT interpreter, …; that is, what I called the front-end
>> to JTAPI.****
>>
>> ****
>>
>> I always saw the use case as: A Print Service accepts PWG:PJT but the
>> Print Client produced JDF. Thus, the either the Print Client or the Print
>> Service uses the JTAPI Transform Service to transform JDF to PJT. The
>> Print Service would already have its own interpreter to parse PWG:PJT into
>> what ever internal format the Print Service needed or used. [ I had
>> always hoped that someday we could have a defined a the internal format
>> that everyone would use but I don’t think that will ever happen.]****
>>
>> ****
>>
>> From my use case, JTAPI would need the ability to transform many possible
>> input public and private job ticket formats; JTAPI, itself would have an
>> internally data structure capable of containing content from many input Job
>> Ticket to be able to produce differing output Job Tickets.****
>>
>> ****
>>
>> I am not sure what to do now. I may not be the best person to guide the
>> Daniel on the first JTAPI project since I not seem to have the correct
>> understanding. Ira, perhaps, you should mentor Daniel on the core (the
>> first) JTAPI project so that the actual intent is produced. I will mentor
>> another student for the second JTAPI project following your’s and Daniel’s
>> lead. ****
>>
>> ****
>>
>> Glen****
>>
>> ****
>>
>> ****
>> ------------------------------
>>
>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
>> *Sent:* Sunday, April 01, 2012 9:27 PM
>> *To:* Petrie, Glen; Ira McDonald
>> *Cc:* Daniel Dressler; printing-architecture at lists.linux-foundation.org;
>> printing-summit at lists.linux-foundation.org****
>>
>>
>> *Subject:* Re: [Printing-architecture] [Printing-summit] OPS
>> Preparationminutes (28 March 2012)****
>>
>> ****
>>
>> Hi Glen,
>>
>> I strongly disagree - this is *not* the OP Job Ticket
>> Transform Service.
>>
>> The first use for a client is to create a NEW job
>> ticket (in the abstract API) and write it out into some
>> concrete format (with a backend).
>>
>> Clients mostly won't modify existing job tickets.
>>
>> And PrintServices will just use JTAPI to parse the
>> job ticket once (in whatever format) and use the
>> values in the actual Interpreter and Scheduler
>> miodules.
>>
>> Conversion of Job Ticket formats is the tertiary
>> use case.
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG IPP WG
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - TCG Embedded Systems Hardcopy SG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music/High North Inc
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> mailto: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****
>>
>> ****
>>
>> 2012/3/30 Petrie, Glen <glen.petrie at eitc.epson.com>****
>>
>> Ira, Daniel****
>>
>> ****
>>
>> Since there seems to be an objection with just using “op”; I don’t
>> believe “opjt” is actually correct either. That is, this is not the
>> OpenPrinting Job Ticket; what it is the OpenPrinting Job Ticket Transform
>> Service [which fits perfectly with PWG’s definition of a transform
>> service]. So an alternate and more descriptive lettering would be either
>> ****
>>
>> ****
>>
>> “opjtt” = open printing job ticket transform****
>>
>> “opjtts” = open printing job ticket transform service****
>>
>> ****
>>
>> <The only other suggestion is to change the formal API names (not the
>> prefix) to say JobTicketXXXXXXX and DocObj____. NO!>****
>>
>> ****
>>
>> Glen****
>>
>> ****
>>
>> p.s. ****
>>
>> Please consider that this code will ultimately be reference code; and not
>> reference code for execution as much as for source code on how to make Job
>> Ticket back-ends (and front-end). Having long prefixes for variable,
>> variable types, routine name, etc, makes the code difficult to read,
>> understand and develop. This is not a schema, a dtd or the like; but a
>> set of APIs that must have a front-end and one or more back-ends.
>> Namespace conflicts with JTAPI as a transform service are none since that
>> interface will be determined by the front-end.. Conflicts of actual coding
>> of the front-end and back-ends would be very low. Since back-ends will
>> likely be DLLs, there are not conflicts between back-ends. My request is
>> that, for this project, the code must be well structured, easy to read,
>> easy to following and strongly commented. The goal is not the fastest or
>> the fanciest code but code that other will read and use to develop their
>> code. The code is the instruction manual. ****
>>
>> ****
>>
>> p.s. ****
>>
>> As the PWG moves forward to MFD’s, the notation of a Job Ticket becomes
>> unclear as to what service the Job Ticket is for. So the descriptive
>> lettering should be****
>>
>> ****
>>
>> oppjtt openprinting print job ticket transform****
>>
>> oppjtts openprinting print job ticket transform service****
>>
>> ****
>>
>> or ****
>>
>> ****
>>
>> The current JTAPIs would have to be extended to support other services.
>> Naming will be a real big problem then even considering the commonality
>> among various service job tickets. ****
>>
>> ****
>>
>> p.s. ****
>>
>> I did not see any feedback (or I missed it) to my suggested changes to
>> JTAPI headers to OpenPrinting names (prefixes); thus, I assume the
>> preference is to stay to the existing FSG:JTAPI header file. That is, by
>> all definitions, the correct thing to do. So I guess it make the
>> discussion of prefix unnecessary.****
>>
>> ****
>>
>> ****
>>
>> gwp****
>>
>> ****
>>
>> ****
>>
>> ****
>>
>> ****
>>
>> ****
>> ------------------------------
>>
>> *From:* printing-architecture-bounces at lists.linux-foundation.org [mailto:
>> printing-architecture-bounces at lists.linux-foundation.org] *On Behalf Of *Ira
>> McDonald
>> *Sent:* Wednesday, March 28, 2012 9:18 PM
>> *To:* Daniel Dressler; Ira McDonald
>> *Cc:* printing-architecture at lists.linux-foundation.org;
>> printing-summit at lists.linux-foundation.org
>> *Subject:* Re: [Printing-architecture] [Printing-summit] OPS
>> Preparationminutes (28 March 2012)****
>>
>> ****
>>
>> Hi Daniel,
>>
>> Comments inline below.
>>
>> Cheers,
>> - Ira****
>>
>> On Wed, Mar 28, 2012 at 7:09 PM, Daniel Dressler <
>> danieru.dressler at gmail.com> wrote:****
>>
>> In response to some comments in the meeting.
>>
>> 1. I would prefer an 'op' prefix to 'fsgjt'. I assume fsgjt means free
>> standards group job ticket? Since the fsg does not exist anymore I think
>> 'op' would avoid confusion. And it is shorter.****
>>
>> Do we know of any namespace conflicts with other op libraries? It's been
>> 5+ years, has this situation changed?****
>>
>> <ira>
>> The Open Printing Vector API uses 'opvp' as prefix throughout.
>> It's sloppy and amateur coding practice not to use a library
>> specific unique prefix (e.g., 'opjt') for variables and functions.
>>
>> The scope is NOT just OP libraries, but the entire universe of
>> code that might be linked into a vendor or third-party tool.
>> </ira>
>> ****
>>
>> 2. I will be attending as much of the summit as I can by phone-in, the
>> summit takes place over my finals so I will be missing some sessions.****
>>
>> <ira>
>> Understood - we'll be glad to have you when you can attend.
>> </ira>****
>>
>> 3. If the wiki has no history does that mean it is pointless for me to
>> fill in the change log when making edits?****
>>
>> <ira>
>> Till can hopefully answer this one - we're not any of us happy
>> about the move from a full-function Wiki tool to a limited Wiki
>> tool by the Linux Foundation.
>> </ira>
>>
>> Daniel****
>>
>> ****
>>
>> 2012年3月28日13:38 Ira McDonald <blueroofmusic at gmail.com>:****
>>
>> Hi,
>>
>> Minutes from today's Open Printing Summit planning call are posted at:
>>
>>
>> ftp://ftp.pwg.org/pub/pwg/openprinting/minutes/OP-Summit-Prep-20120328.htm
>>
>> Note: New FTP directory - see above
>>
>> - ACTION - Till - contact Linux Foundation about Glen/Hin-Tak updates
>> to GSoC projects - no website fall-backs allowed until late April
>> - OPEN
>>
>> - ACTION - Till - contact Ghostscript and other color management folks
>> as presenters (or send slides?)
>> - Michael Vrhel (Artifex, Ghostscript) will attend OPS
>> - OPEN
>>
>> - ACTION - All - Draft presentation slides/outlines for review 11 April
>> - OPEN
>>
>> - ACTION - Presenters - tell Till EARLY about any special requirements
>> (e.g., speakers for video, demo printers, etc.)
>> - OPEN
>>
>> - ACTION - Presenters - send PDF slides to Till EARLY (or upload to OP)
>> (so that participants can download slides as backup for screencast)
>> - OPEN
>>
>> - ACTION - Ira - draft slides for OP Plenary by 11 April
>> - OPEN
>>
>> Next OP Conference Calls:
>> (1) April 2012 - OPS Preparation
>> - Note - US Daylight Savings Time started on Sunday 11 March 2012
>> - Note - Europe Summer Time started on Sunday 25 March 2012
>>
>> - Wednesday 11 April 2012, Daytime
>> - US
>> 9am in **San Francisco** - ****US**** PDT (Pacific Daylight Time)
>> 10am in **Colorado** - ****US**** MDT (Mountain Daylight Time)
>> 11am in Chicago - ****US**** CDT (Central Daylight Time)
>> 12pm in **New York** - ****US**** EDT (Eastern Daylight Time)
>> - **Europe**
>> 6pm in ****Berlin**** - CEST (Central European Summer Time)
>>
>> * Main Number (Till Kamppeter, LF, leader)
>> International: +1-218-936-7999
>> Access Code: 491659#
>>
>> (2) April 2012 - Joint PWG / Open Printing ****Summit****
>> - Note - OPS is NOT hosted by Linux Foundation Collaboration Summit
>>
>> - Tuesday to Friday 24-27 April 2012 at Apple in ****Cupertino**, **
>> CA****
>> - US
>> 9am in **San Francisco** - ****US**** PDT (Pacific Daylight Time)
>> 10am in **Colorado** - ****US**** MDT (Mountain Daylight Time)
>> 11am in Chicago - ****US**** CDT (Central Daylight Time)
>> 12pm in **New York** - ****US**** EDT (Eastern Daylight Time)
>> - **Europe**
>> 6pm in ****Berlin**** - CEST (Central European Summer Time)
>>
>> * Main PWG Number (Mike Sweet, Apple, leader)
>> US Toll-Free: +1-866-469-3239
>> International: +1-650-429-3300
>> Access Code: By request to Ira McDonald (do NOT publish)
>>
>> (3) May 2012 - US/Europe - OP Monthly Meeting
>> - Note - Joint PWG/OPS is 24-27 April at Apple in ****Cupertino**, **
>> CA****
>> - Note - Ubuntu Developer Summit is 7-11 May in ****Oakland**, **CA**
>> **
>> - Note - Ira has a conflict on 16 May
>>
>> - Wednesday 23 May 2012, Daytime
>> - US
>> 9am in **San Francisco** - ****US**** PDT (Pacific Daylight Time)
>> 10am in **Colorado** - ****US**** MDT (Mountain Daylight Time)
>> 11am in Chicago - ****US**** CDT (Central Daylight Time)
>> 12pm in **New York** - ****US**** EDT (Eastern Daylight Time)
>> - **Europe**
>> 6pm in ****Berlin**** - CEST (Central European Summer Time)
>>
>> * Main Number (Till Kamppeter, LF, leader)
>> International: +1-218-936-7999
>> Access Code: 491659#
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG IPP WG
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - TCG Embedded Systems Hardcopy SG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music/High North Inc
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> mailto: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****
>>
>> ****
>>
>> _______________________________________________
>> Printing-summit mailing list
>> Printing-summit at lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/printing-summit****
>>
>> ****
>>
>> ****
>>
>> ****
>>
>> ****
>>
>> ** **
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20120402/19fb78e2/attachment-0001.html>
More information about the Printing-architecture
mailing list