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
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: cloud-bounces at pwg.org<mailto:cloud-bounces at pwg.org> [mailto:cloud-bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Monday, December 03, 2012 11:02 AM
To: cloud at pwg.org<mailto:cloud at pwg.org>
Subject: [Cloud] Feedback on proposed Cloud Print extensions
All,
I've posted this feedback in slide form at:
ftp://ftp.pwg.org/pub/pwg/cloud/white/cloud-extension-comments-sweet-20121203.pdf
This feedback is based on my work on IPPSIX, the IPP binding spec for this stuff...
.....
GetAvailableJobs
- Don't like being able to get jobs for multiple Printers
- Doesn't match existing SM or IPP Printer objects - the Client
is always talking to a single service endpoint/target, not
multiple services/targets
- Existing model does not preclude having a Cloud Print Manager
that fronts multiple output devices
- 1 Cloud Print Manager with multiple output devices
sharing the same Cloud Print Service, or
- N Cloud Print Managers (implementation might merge
these) each using their own Cloud Print Service
<PZ>
One primary reason for this was to enable cloud printing for legacy devices. In my implementation I could map multiple "Cloud Print Managers" to a single "Cloud Print Service". In my implementation a "Cloud Print Manager" could operate as a printer or a proxy. I have no objection to the simplification so it complies with the Cloud Print model as it stands today.
</PZ>
- 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.
The other shortcoming of GetJobs is that it reports the state of the Jobs within the "Cloud Print Manager". 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".
* This is what is used by Google Cloud Print (See <https://developers.google.com/cloud-print/docs/devguide#fetching>)
* The capabilities exposed and the processing of PrintJobTickets is already covered. I see no value in exposing this in yet another way. Let the User specify what processing is needed for the job. The protocol already handles the negotiation. The current data model already handles the capabilities and the defaults. If one of the Cloud Components, or the Printer itself, has augmented capabilities those should be hidden from the print path. The only time it should appear on the wire is when one of them contracts with an external service (e.g. PWG TransformService, Google Docs). Then the transform must be represented between those two entities.
</PZ>
- Cloud Print Service advertises capabilities
(FetchDocumentElementsSupported,
FetchDocumentPWGRasterDocumentTypesSupported,
FetchDocumentPWGRasterDocumentResolutionsSupported)
- Cloud Print Manager includes DocumentTicket in FetchDocument
request
- Includes additional elements for output format
(DocumentFormat/Details, PWGRasterDocumentType,
PWGRasterDocumentResolution)
- Cloud Print Service will need to fetch data from
Document URI
- Do we define when that happens?
- What about caching?
User Role "Printer"
- When characterizing access control policies, we often use
"adminstrator", "operator", "user", and "system" as user
roles
- For Cloud Print we need a new role for the printer/ Cloud
Print Manager
- Printers can fetch documents, users probably can't
(although there is a use case for users viewing
documents they have submitted...)
- Most of the other Cloud Print operations are probably
printer-only
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
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/213b0474/attachment-0002.html>