[Cloud] How different is Cloud Print from our currently defined Print Service

[Cloud] How different is Cloud Print from our currently defined Print Service

Randy Turner rturner at amalfisystems.com
Sun Aug 26 18:27:33 UTC 2012


Hi Pete,

This reminds me of a comment I made last year at a Face-to-Face that cloud printing is a minor delta from just network printing, and there may be no reason to re-visit every operation.  In a typical office environment, we've always had clients,  and then a print server that supports operations related to queuing and other functionality.

We're basically moving the server outside of a firewall, so we may need to address aspects of the service  that need to be added for firewall (or other security domain traversal), and not necessarily re-visit "printing".

In other words, the bulk of the job of supporting cloud printing may be the work that we've heretofore decided not to address yet (authentication, authorization, etc.).

in past messages, I have also recommended we look at XMPP as a potential protocol we could re-use for certain functionality related to cloud printing, although not necessarily as a print job transfer protocol (or what lately I've been referring to as a "bearer" channel). However, XMPP can be used for just about any of our other functionality, which I like to call "signaling" -- I've borrowed these terms from the SIP world, where they have a signaling protocol that does a lot of "setup" or negotiation of the bearer channel, and then the "bearer" protocol is often some other protocol that specializes in bulk data transfer.


Randy


On Aug 26, 2012, at 5:57 AM, "Zehler, Peter" <Peter.Zehler at xerox.com> wrote:

> 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
> 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. _______________________________________________
> cloud mailing list
> cloud at pwg.org
> https://www.pwg.org/mailman/listinfo/cloud


-- 
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/03983f77/attachment-0002.html>


More information about the cloud mailing list