Pete,
Agreed, and I appreciate everything you have done to get the ball rolling - definitely allows us to flesh out the details as needed...
On 2012-12-04, at 10:29 AM, "Zehler, Peter" <Peter.Zehler at xerox.com> wrote:
> All,
> My comments are inline below. Keep in mind that the initial straw man proposal is based on a prototype that was done more than three years ago. Things have changed and the WSDL/Schema will evolve to represent the groups consensus. But at least it is a “concrete” start.
> Pete
> ...
> - But why have GetAvailableJobs at all?
> - Existing GetJobs operation provides all the info needed
> - Notifications tell you which printer needs to be polled
>> <PZ>I disagree.
>> The attributes returned from a GetJobs are job state related. What a “Cloud Print Manager” requires to decide what Jobs to schedule is JobTicket related. I believe an implementation or deployment requirement is that either the “Cloud Print Service” or the “Cloud Print Manager” should be able to resolve Job Scheduling. We want this to scale from low end printers all the way up to the tree eaters. If the “Cloud Print Service’s” role is job scheduling, it would only return a single job entry at a time. If the “Cloud Print Manager’s” role is job scheduling, it would return a list of job entries at a time along with the information pertinent to job scheduling.
At least from the IPP perspective, Get-Jobs can be used to obtain any Job Description or Job Template values for a list of jobs in the requested state(s), and those jobs are returned in the Printer's (Cloud Print Service's) queue order (i.e., most important/recent to least important/recent) so the client (Cloud Print Manager) can not only get all of the pertinent information it needs about pending jobs but also choose which job to process based upon any strategy or preference.
> The other shortcoming of GetJobs is that it reports the state of the Jobs within the “Cloud Print Manager”.
I don't see that; certainly the Cloud Print Service will reflect some of the job state that the Cloud Print Manager sends up to it, but ultimately the CPS is managing the original job, not the CPM. All the CPM can say is "yep, I've processed this job and it is now completed", but the CPS might continue reporting "processing" until it has completed *its* processing of the job along with a corresponding job-state-reasons keyword that tells the client that the output device has completed processing.
> I see no reason that a Job with a JobState of either ‘Pending’ or ‘processing’ might not be available to forward onto a “Cloud Print Manager”. However I do not see a requirement that either state would mandate that a Job is available to forward onto a “Cloud Print Manager”. I see no problem in a “Cloud Print Service” acting as a dumb queue or as an active entity providing augmented processing over and above that provided by the target “Cloud Print Manager”.
> </PZ>
>>> FetchDocument
>> - Need basic transform functionality
>> - Request that the document data be transformed to a
> suitable format for printing, such as “I need PWG
> Raster data in 8-bit grayscale at 300dpi”
>> - This is used by Google Cloud Print and other
> implementations
>> - Also covers things such as copy generation, scaling,
> number-up, etc.
>> <PZ> I disagree.
>> · The existing capabilities framework (i.e. xxx-supported) takes care of this. The Printer itself can declare the DocumentFormats that it is able to consume. The “Cloud Print Manager” based on the PrinterCapabilities and any of its own capabilities, can declare the DocumentFormats it can consume and forward onto the Printer. Furthermore the supported DocumentFormats could be constrained as well. Note that some transform may take place at the “Cloud Print Manager” either internally or through a contract with an external TransformService. Finally when the “Cloud Print Service” is associated with the “Cloud Print Manager” the formats that are exchanged is limited to the DocumentFormatsSupported of the “Cloud Print Manager”. Of course the “Cloud Print Service” can offer any DocumentFormatsSupported as long as it is able to transform it into one of the required DocumentFormats of the “Cloud Print Manager”. Of course that can be done internally or through a contract with an external TransformService. From an end user point of view the critical behavior is that the “Printer” (i.e. Cloud Print Service”) can accept the DocumentFormat of the user and the appropriate marked media comes out of the target “Printer”.
>
OK, so previously you advocated a hands-off approach for the Cloud Print Service, but here you clearly indicate that the CPS will be an active party doing a lot of processing on behalf of the CPM, before it is even potentially ready or willing to fetch that job.
> · This is what is used by Google Cloud Print (See <https://developers.google.com/cloud-print/docs/devguide#fetching>)
>Yes, and there is says that the printer asks for the format in the fetch request:
The file is available in PDF, PWG-raster (March 2011 draft), or in the original format of the document.
My reason for advocating providing a transform ticket in the fetch request is basically because I find the GCP interface too simplistic - their server decides what the printer will want based upon the static PPD/XPS information. I know from experience that this model is not optimal, and vendors jump through a lot of hoops to work around limitations in the static capabilities of PPDs in their CUPS drivers. It also does not allow for fallback modes - consider a PDF-capable printer that only has storage for PDFs up to ~20MB. If the CPM sees the submitted PDF is too large or (after processing) sees it is too complex to print as PDF, it can go back and ask for a PWG Raster version of the document that *can* be printed.
Requiring a separate transform service (which the CPM has to discover/be configured with) seems clumsy and not in keeping with how we have defined other services and extensions for IPP and the SM (which contain a lot of simple transform-like attributes/elements already...)
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20121204/e721f0ca/attachment-0002.html>