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#LinkFF5>. 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<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
--
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/20121105/8b1e2286/attachment-0002.html>