Glen,
On 2013-04-17, at 10:53 AM, "Petrie, Glen" <glen.petrie at eitc.epson.com> wrote:
> Hi,
>> On Monday's meeting, Paul brought up a question of the other job-submission connections (i.e. direct network connection) to a Printer (to the Print Manager) other than the Cloud connectivity we are discussing in this group. This brings up the question of whether other job-submission should be reported or not. That is, is it important or is it needed to be known "how busy a printer is". Without knowing "all" the print jobs associated with the printer true loading cannot be determined. This assumes the Print Manager manages all job for a printer no matter the submission source.
That is, IMHO, an incorrect assumption.
Based on the work done both in the Cloud and IPP WG's, the Manager is a gateway and doesn't do any job management on its own. For Output Device(s) with a local Print Service, the Print Service manages all jobs for the Output Device(s) with the Manager "spoon feeding" it with jobs from the Cloud Print Service. When a job is canceled at the Cloud Print Service, the Manager relays that state change by telling the local Print Service to cancel its job as well. When a job is canceled/aborted at the local Print Service, the Manager relays that state change by telling the Cloud Print Service to update the job state. About the only "management" the Manager does in this configuration is to its "secret decoder ring" which maps Cloud Print Service jobs to local Print Service jobs.
When the Manager communicates directly with the Output Device(s) (no local Print Service) then the Cloud Print Service provides all of the job management and the Manager just relays document data and state/config changes between the two. Here the Manager may also need to maintain a cache/data store for the current Output Device state(s) and configuration(s), but the actual job management is done exclusively by the Cloud Print Service.
> If no requirement – "A Print Manager "MUST NOT" (or at least "SHOULD NOT") report to the Cloud Print Service jobs originating from other job-submission services (i.e. a network print service)."
The Manager can only report job state for jobs that exist in the Cloud Print Service.
However, the Manager *can* report Output Device state showing that jobs are being processed, and how many jobs are queued up ("queued-job-count" in IPP, I think "QueuedJobCount" in SM, not 100% sure), but the Cloud Print Service will never know the details behind the curtain.
> Or
>> If there is a requirement – "A Print Manager "MUST" (or at least "SHOULD") report to the Cloud Print Service the total number (and size?) of "all" print jobs no matter the originating job-submission services."
The Semantic Model and IPP do not currently have a way to report the "size of work" queued for a printer, although that would be an interesting addition. Right now all that is exposed is the (optional) number of jobs that are queued.
(But if you'll remember the discussions for the Transform service, coming up with metrics to express the amount of work or capacity to do work can get very tricky.)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/20130417/2bbba71b/attachment-0002.html>