[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)
Ira McDonald
blueroofmusic at gmail.com
Mon Apr 2 15:12:18 UTC 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/53df8089/attachment-0001.html>
More information about the Printing-architecture
mailing list