[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)
Daniel Dressler
danieru.dressler at gmail.com
Mon Apr 2 17:37:48 UTC 2012
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/8b942bd3/attachment-0001.html>
More information about the Printing-architecture
mailing list