Hi Peter,
Your description sound a lot like DocuPrint or a (Production) Print
Manager. Is this a good Cloud-Print model? It could be, since
DocuPrint like entities have been around more than two (maybe three)
decades. Terminology, I believe, is a little different today. The
other aspect I note, and, again, it more in line with a production print
model (like DocuPrint), is your model is a pull-model from the physical
printer out of a print queue; while my model is a push-model to the
physical printer. While I have actually been involved in studies that
show the pull-model is beneficial for production printing, I don't yet
have the same understanding that a pull model is beneficial for Cloud
Printing.
Print Queue (Print Queue) = Print Service
* Assuming a Print Service can hold (queue) more than a single job.
The Print Service is its own Print Manger. Is this the desired
functionality? Maybe
* An opposing model is for a new instance of a Print Service is
created for each Print Job. This begs the question of who manages the
multiple instance of a single Print Service. Thus, a Print Manager
for the multiple instances of a Print Service is still required.
* I believe this means there must be a Print Manager; called it the
Cloud Print Manager.
o Could the Cloud Print Manager allow implementation of either or
both types of Print Services models (pull and/or push); sure.
Printer = Printer (maybe
this means the Print Service of the Printer)
You also discuss the idea that a Print Job is on a Printer. That may
or may not be true depending the size and capabilities of printer. This
may be true for some office and most production printers but as you move
down is physical printer size there is no need for the physical printer
to ever have or know about a/the Print Job. The physical printer's
Print Service knows about the Print Job. One of the advantages of
Cloud Print is that all of the "printing smarts" (jobs, driver,
transform, rendering, etc) can actually be in or by a/the cloud based
Print Service and very little, beyond status and base printing
functionality (think processing vendor specific PDL) needs to be in the
actual physical printer. This means the physical printer is not IPP
based; it would be the Print Service (maybe).
This brings up the concept that perhaps the Cloud Print Manager creates
an instance of a Print Protocol front-end (like IPP) and connects to an
internal protocol neutral instance of a Print Service!!!! Thus, if a
Print Client supports a different Print Protocol, a different front-end
is spawned!!! Not one protocol configuration will fit all solutions but
since Cloud supports real-time configurability of services in general,
any Cloud Print Manager/Solution should take advantage of this. So, no
Cloud Printer Manager is tied to a single protocol but will (may) be
required to support different ones.
Support for fan-in and fan-out in the traditional sense is "behind the
scene" and an implementation detail within a specific Cloud Print
Manager / Solution implementation. Maybe what you describe below is
more like federation of Cloud Print Manager. The other part of your
discussion on queues is about User specific capabilities. I agree this
is needed functionality; the spawning of a Print Service instance makes
this functionality easy. When the Print Service is spawned, the
capability data of that Print Service only includes those allowed
capabilities available for the User. This action is additive; that is,
if there site or department policies restricting the User capabilities;
those capabilities can also be removed for the capability data for a
specific Print Service instance.
The way I see the processing (workflow) of Cloud Print Job is not from
the pull-model (that is, from printers or queues perspective of checking
to see there is a Print Job to do (do I want potentially thousands upon
thousands of physical printers sending internet messages to Cloud Print
Queues of Cloud Print Solution checking to see if there is something to
print!) ) but rather from a push-model from the User. That is User
makes a Print Request to the Print Cloud Manager, a Print Service is
selected, if the specific Print Service does not always exist; then, an
instance of the selected Print Service is spawned based on User
permission and site policies, a Print Client creates the User's Print
Intent from the Print Service capabilities, the Print Service (including
physical printer) status is checked, the Print Intent is passed to the
Print Service to become a Print Job (actually I like the concept that
Print Client to create a Print Job and simply passes it to the Print
Service but this is not generally agreed upon by others), the Print Job
starts, status is reported as required/requested, the Job finishes.
I don't understand the concept of "lock the job"; to me, once the Print
Service accepts the Print Job (not error in the Print Job Ticket) that
it is.
I believe that is registration is not just about the printer; but about
the User and the printer.
Glen
________________________________
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Zehler, Peter
Sent: Tuesday, December 13, 2011 5:34 AM
To: cloud at pwg.org
Subject: [Cloud] Cloud Print binding to IPP
All,
I would like to see an IPP binding for Cloud printing. I see a
significant advantage to an IPP based solution given the maturity of the
protocol and the industry wide support. I experimented with a cloud
based print service back in 2009. I based my experiments on a WS-Print
binding but an IPP binding would also work. I switched the binding from
WS-Print to PWG SM and included it in v1.160 of the PWG SM Schema. It
is easier for me to write Schema than IPP and easier to display. It is
not difficult to move between the two mappings. The issues I did not
address include an environment agnostic registration and a common
security model.
For clarity I will refer to the Cloud based Printers as Queues and the
devices as Printers even though in the IPP model they are both
implementation of IPP Printers. In v1.160 of the PWG Semantic Model
Schema I included two files (i.e., PwgCloudPrintQueue.wsdl and
PwgCloudPrintQueueMsg.xsd) that have some of the operations fleshed out
a bit. (I dropped a couple things moving from WS-Print to PWG SM.)
I had a couple of assumptions going in.
I believe that Queues and Printers contain Jobs and are stateful. There
is an association between the Jobs in a Queue and the Jobs being printed
on a Printer. A mapping between them should be maintained on both sides
and carried explicitly in the protocol. I do not believe we should be
implementing "remote markers" where Jobs only reside in the Cloud. It
should be possible for either side to use IPP operations to query the
state of the Printer/Queue and their Jobs.
I believe it is a requirement that the Cloud Print model must support
both Fan Out and Fan In. In other words it should be possible for a
single Cloud Queue to act as a proxy for other Cloud Queues. This will
allow a Printer to interact with a single Cloud Queue but still service
jobs in multiple Cloud Queues. Taking this approach allows you to do
things such as set different default behaviors for Queues that all map
to the same Printer. (The User does not need a Job Ticket since the
intent is associated with the various Queues.) This approach also allows
you to enforce different capabilities for different users. Users have
permission to use specific Queues. The Queues could prohibit color
printing or limit the size of a Job.
It should also be possible for one Printer to interact with a Queue and
forward Jobs to other Printers. For example a Printer in an enterprises
DMZ could forward jobs to internal Printers or a software only Printer
could front end legacy devices (i.e., proxy).
The way I broke the processing of Cloud Jobs up was; Check for Work,
Lock the Job, Update the Job Status, Retrieve the Document(s), and
Finish the Job. I also had another group of things that include;
synchronization of Printer and Job state, Firewall Traversal, Moving
from Poll Driven to Event Driven, and Eventing.
Check for work:
The Printer should be event driven when processing Jobs. See below for
a discussion on eventing. The printer should query the Queue for
available work.
The Operation IsThereAnyWork
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Li
nk1036>
is used by the Printer to ask a Queue to see if any work is available.
The request contains a list of DestinationServiceUuids (i.e.
printer-uuid) where the Jobs will be printed. The response will have a
list of work entries. Each entry contains the SourceServiceUuid,
DestinationServiceUuid (missing in schema) and a list of Job ids. I
used a UUID instead of an ID but as long as the source Queue is
identified either would work.
Lock the Job:
Once a Printer has determined the job it will process, it sends a
DeQueuePrintJob operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Li
nk1035>
to the Queue. This operates a little differently than CreateJob in
that the Printer Job identifier needs to be reserved until the operation
succeeds. If the operation fails or times out the identifier and any
allocated resources are discarded. The request includes the identifiers
for the source and destination Queue/Printer and Jobs. The response
contains the number of documents in the job as well as some job
information such as the job name and owner. Although not included a
JobTicket should be passed in the response as well. The payload of the
response should closely match a CreateJob operation. We may also want
to consider passing a JobTicket by reference which IPP does not permit
at this time.
Update the Job Status:
Event notifications are used to keep the state of the Job, Document and
Service updated. I used WS-Eventing but an IPP notification method can
be substituted. See eventing discussion below.
Retrieve the Document:
The Printer retrieves the documents to process using the Retrieve
Document operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Li
nk1038>.
The request identified the source Service, Job and Document number. The
response includes the document number and a flag to indicate if it is
the last document. Other information such as a Document Ticket or the
DocumentFormat can also be included. Since the Printer does not know if
the document will be pushed or pulled it must be ready to accept a
DocumentUri or Document Content in the response. I used MTOM but IPP
already has an acceptable encoding. It is most efficient to use print
by reference whenever possible.
Finish the Job:
Once the Job has been printed the final update of the Job is done. Note
that events are used to handle updates as the Job is being processed.
The CompleteDequeuePrintJob operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Li
nk1034>
request contains the Source and destination Queue/Printer and Jobs and
the details of the Destination Job. Included is The JobState, any
JobStateReasons, DateTimeAtCompletion and the ImpressionsCompleted. The
PrintJobReceipt can also be included.
Synchronize Printer/Queue state,
Synchronize Job state,
Moving from Polling to Event Driven
Firewall traversal
Eventing:
This nice thing about outbound (i.e., Printer to Queue) eventing in a
Cloud environment is that no event subscription needs to be sent. The
Printer knows the Queue is interested in Printer and Job events. Either
a well-known listener port can be used or the location can be part of
registration. Since the Printer knows which jobs came from the Cloud it
can filter the Job events. Whenever a Printer is initialized a printer
state event should be sent to its registered Queues. If the content of
the event is insufficient then a one way message that looks like a
GetPrinterAttributes operation response could be used.
In order to move from a poll model to an event driven model we need a
mechanism to traverse the firewall. I originally used a hacked together
HTTP trickle protocol. A standardized protocol such as XMPP can be used
instead. The PWG can create PWG specific stanzas that map to existing
IPP operations such as GetPrinterAttributes, GetJobs or
GetJobAttributes. A new stanza would be needed to let the Printer know
it's time to send an IsThereAnyWork operation to a Queue.
Registration:
I did not do anything with registration other than put in a place
holder. The RegisterPrinter operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Li
nk1037>
request contains some Printer information such as the identifier for the
Queue and the Printer. It was not clear to me if the existence of a
Queue is a prerequisite or a result of the operation. The Printer
information would also include the PrinterCapabilities that we recently
defined in the Job Ticket work. This contains the defaults,
capabilities and document generation information. I included some
"Agent" information. I assumed there would be some security information
exchanged so I just put a placeholder there.
Comments?
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 <http://www.mailscanner.info/> , 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/20111213/cb1bb6cb/attachment-0002.html>