All,
As I mentioned at the Face to Face, my view is that both the Cloud Print
Service and the Cloud Print Manager look like PWG Printers. I believe
it is an absolute requirement that the Cloud Print Service make the
usual client print operations available to a Cloud Print Client (e.g.,
CreateJob, SendPrintDocument, SendPrintUri, ClosePrintJob,
GetPrinterElements). I see no reason that the Cloud Print Manager would
not implement those same operations. The limitation for the Cloud Print
Manager is those operations are only available to the Cloud Print Client
if the Cloud Print Client has network access to the Cloud Print Manager.
Of course a Cloud Print Manager could be implemented so that the only
way to submit a job to it is through a Cloud Print Service.
(Note lists below are not authoritative or are the operation necessarily
in the right group.)
The list of possible user operations include: CancelPrintDocument,
CancelPrintJob, CancelMyPrintJobs, ClosePrintJob, CreatePrintJob,
GetActivePrintJobs, GetActivePrintJobs, GetPrintDocuments,
GetPrintJobElements, GetPrintJobHistory, GetPrintJobs,
GetPrintServiceElements, IdentifyPrinter, PrintJob, PrintUri,
ReprocessPrintJob, RestartPrintJob, ResubmitPrintJob, SendPrintDocument,
SendPrintUri, ValidatePrintDocumentTicket, ValidatePrintJobTicket,
The administrative operations include: ActivatePrinter,
CancelCurrentPrintJob, CancelPrintJobs, DeactivatePrintService,
DisablePrintService, EnablePrintService, HoldNewPrintJobs, HoldPrintJob,
PausePrintService, PausePrintServiceAfterCurrentJob, PromotePrintJob,
PurgePrintJob, ReleaseNewPrintJobs, ReleasePrintJob,
RestartPrintService, ResumePrintJob, ResumePrintService,
SetPrintDocumentElements, SetPrintJobElements, SetPrintServiceElements,
ShutdownPrintService, SuspendCurrentPrintJob
I see no reason why any of these operations would not be applicable to a
Cloud Print Service or a Cloud Print Manager. If we have some
administrative scenarios from IPP, they can probably be reused. The
interesting part come when discussing the upstream/downstream behavior.
For example an administrator of a cloud print service is informed a
specific printer will be down for a week waiting for a required part.
The administrator wants to prevent more jobs from accumulating for this
commonly used printer. The administrator disables the printer.
Currently defined administrative operations affect the service to which
the request is directed. In a fan out configuration, which may be
likely in cloud environments, must an operation on the Cloud Print
Service affect the downstream Cloud Print Managers identically? Is
there any way to Pause a Cloud Print Service such that only the Jobs
destined for a specific Cloud Print Manager are affected? I'm inclined
to think that the only way to accomplish this would be to Disable the
specific Cloud Print Service bound to the target Cloud Print Manager
instead of a Cloud Print Service that acts as an aggregator for fan out
printing.
(Note that the operation names below are based on the current straw man
operations in the PWG Semantic Model Schema.)
The operations that are new from the Cloud Print Manager to the Cloud
Print Service would be calls to determine if any Jobs are available,
retrieve a Job, retrieve a document and operations to update the Cloud
Print Manager on the state of the Job/Document at the Job Print Manager.
An operation is also needed to inform the Cloud Print Service of the
state of the Cloud Print Manager.
GetAvailableJobs would return 0, 1 or more jobs. The response would be
a list of job summaries. Of course 0 would be returned if no work is
available. The question then is which entity controls Job Scheduling.
I see no reason the model should take a position. If the Cloud Print
Service controls Job Scheduling, then one Job would be returned at a
time. If the Cloud Print Service is not controlling Job Scheduling,
then a list of Jobs can be returned. The Job Summary information needs
to be sufficient for basic Job scheduling.
FetchJob allows the Cloud Print Manager to select a Job in the Cloud
Print Service for processing. Appropriate metadata, including the
PrintJobTicket, is returned. The selected Job in the Print Cloud
Service is no longer available to other Cloud Print Managers.
ReportJobState/ReplyToJob is used by the Cloud Print Manager to keep the
Cloud Print Service up to date on the status of the processing Job or
when it has reached a terminated state. The current operations are
split into a general update and one used after Job creation. Time will
tell if both are needed.
FetchDocument is used by the Cloud Print Manager to process a Document
within the specified Cloud Print Service Job. Included in the response
are the appropriate metadata, including a PrintDocumentTicket, if
present, and the document content or reference URL.
ReportDocumentState/ReplyToDocument is used by the Cloud Print Manager
to keep the Cloud Print Service up to date on the progress of the
processing of the Job's Document or that it has reached a terminated
state. The current operations are split into a general update and one
used after Job creation. Time will tell if both are needed.
ReportPrinterState is used by the Cloud Print Manager to keep the Cloud
Print Service apprised of its state changes including changes to
defaults or capabilities.
The operations are currently modeled as requests from the Cloud Print
Manager to the Cloud Print Service. The main reason for this is that in
a Cloud environment it is assumed that the Cloud Print Client has
network access to the Cloud Print Service and the Cloud Print Manager
has network access to the Cloud Print Service. The reverse is not
necessarily true. For example a Cloud Print Manager may be behind a
firewall. A poll only model between Cloud Print Managers and Cloud
Print Services in less than optimal. The Cloud Print Service should be
able to send events to Cloud Print Managers (e.g., I have work for you).
The Cloud Print Manager would have to be responsible for the
establishment of that channel to allow for firewall traversal. An IETF
standard, such as XMPP (rfc6120), would probably meet our requirements.
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/20120826/7d0c895a/attachment-0002.html>