[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)

[Petrie, Glen]

The issue with the MJT is if we want to change something, then we need
to go back to the PWG.   But, unless Ira disagrees, I see no reason to
change the MJT for this phase of the JTAPI development.    Perhaps, the
MJT will not exercise all of the functionality of the JTAPI; in that
case, we will add a "vendor extension" which would actually be a good
thing, because JTAPI must handle vendor extension at some point.

 

Glen

 

 

________________________________

From: printing-architecture-bounces at lists.linux-foundation.org
[mailto:printing-architecture-bounces at lists.linux-foundation.org] On
Behalf Of Daniel Dressler
Sent: Monday, April 02, 2012 2:27 PM
To: Petrie, Glen
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)

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20120402/501eaf21/attachment.html>