Hello Peter,
We did not have a chance to discuss your proposed cloud-oriented operations
yesterday, with the intended Cloud call falling on a (perhaps largely
unobserved) national holiday. Thank you for these suggestions; I suspect
that they will be the basis of the Cloud Printing Requirements and Model
document. Since the next Cloud call is a combined IPP/Cloud conference call
concerned primarily with December face-to-face meeting preparations, the
discussion of these operations will be scheduled for the face-to-face. This
is probably good in that there is a larger group and we are more likely to
have the majority of participants that have strong opinions on this. I hope
that you will be able to join us, if not in person, at least via phone
bridge.
I would also encourage comments on the mail list. I admit to being a little
confused about what operations are initiated by the Cloud Print Manager and
what by the Cloud Print Service, since the job request is now coming from
the Cloud Print Service, but because of the firewall situation, probably
cannot be initiated by the Cloud Print Service. The new operations are
pretty clear, but I have a problem with many of the existing operations.
For example, in applying Disable Print Service, is the Cloud Print Manager
really going to have the ability to disable the Cloud Print Service? Etc.
Thanks,
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Zehler, Peter
Sent: Monday, November 05, 2012 9:29 AM
To: cloud at pwg.org
Subject: [Cloud] Updated PWG SM posted with straw man cloud operations
(Cloud Print Manager to Cloud Print Service specific)
All,
I have posted v1.182 of the semantic model and the links are available from
the PWG Semantic Model page <http://www.pwg.org/mfd>. (Note: please check
the version number for the Semantic Model v2 Schema links. If it is not
v1.182 dated October 30th, refresh the page to clear the mysterious faulty
cache we seem to have.) The easies view of the operations is from
<http://www.pwg.org/mfd/navigate/PwgSmRev1-182_ServiceOperations.html#LinkFF
5>. The Cloud Print manager and Cloud Print Service specific operations are
shown in their own sequence at the bottom of the diagram of the currently
defined Print Service operations.
The new operations are:
GetAvailableJobs:
Returns the list of jobs ready to be fetched for each of the Printers
requested. In the simple case the number of Printers will be one. Higher
end "Output Managers" can front end a number of Printers. The API also
accommodates job scheduling at either the Cloud Print Service or the Cloud
Print Manager. When the Cloud Print Service is handling job scheduling the
list of jobs returned will always contain a single Job for a Printer. The
current definition returns a list of JobUuids. To properly enable Cloud
Print Manager job scheduling a job summary element group (i.e., job summary
collection in IPP) should be returned. Included in the summary will be the
job identifier as well as some minimal set of information useful for
scheduling (e.g., Finishings, Media, PrintColorModeType, Sides)
FetchJob, ReplyToJob:
This set of operations are similar to the IPP CreatePrintJob operation. The
FetchJob response is analogous to the request portion of CreatePrintJob.
This is where the operational attributes (e.g., RequestingUserName,
JobPassword) are passed as well as the Job's PrintJobTicket. The ReplyToJob
request is analogous to the CreatePrintJob response. This is where the
newly created Job's JobUuid is returned along with any UnsupportedElements.
As an optimization some appropriate state information is included.
FetchDocument, ReplyToDocument:
This set of operations are similar to the IPP SendPrintDocument/SendPrintUri
operations. . The FetchDocument response is analogous to the request
portion of SendPrintDocument/SendPrintUri. This is where the operational
attributes (e.g., RequestingUserName, JobPassword) are passed as well as the
Document's content (i.e., data itself or a reference to it). For
implementations that support it a DocumentTicket can also be passed. The
ReplyToDocument request is analogous to the SendPrintDocument/SendPrintUri
response. This is where the newly created Document's DocumentUuid is
returned along with any UnsupportedElements if applicable. As an
optimization some appropriate state information is included.
UpdatePrinterState, UpdateJobState, UpdateDocumentState:
This set of operations is used by the Cloud Print Manager to inform the
Cloud Print Service of its changes in state. Each of the operations sends
sparsely populated object of the appropriate type. For example if the
configuration of a Printer changes then the UpdatePrinterState request would
contain only the relevant portions of the Printer's
PrintServiceConfiguration. If media was added, removed or changed in an
input tray the InputTrays element group would be returned. Another example
is if the Printer completes a Job. The UpdateJobState request would contain
the elements in PrintJobStatus that have been changed and a final version of
the PrintJobReceipt.
I looked at separating out operations for config changes vs. status changes
but from a wire representation I did not see much difference. From an
implementation point of view not only was the dispatch logic simplified but
also it allows for combining of multiple operations into a single request.
For example a configuration change (e.g., change media in a tray) can affect
capabilities.
Peter Zehler
Xerox Research Center Webster
Email: 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
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, 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/20121113/49049889/attachment-0002.html>