Glen,
Please continue to comment. I value your input. It helps me to clarify
my thoughts. Another viewpoint helps a lot more than the silent
monitoring of discussions of the PWG.
We always seem to talk past each other a bit. I am discussing Cloud
Print from a protocol specific view. Note that I strayed from the
functional model we drew up at the February meeting.
<ftp://ftp.pwg.org/pub/pwg/cloud/slides/cloud-printing-bof-february-11.p
df> In my original post I addressed only the job processing aspects of
the "Cloud Print Provider" I did not address discovery, or selection
and only touched on registration since it involves capabilities. I'm
not forgetting them it's just that I never pursued them in a form I
believe is useful to the PWG. I did not mention the IPP Clients but I
expect that is what would be sending the jobs to the Queue.
As I mentioned both the Queue and the Printer are IPP Printers. From a
protocol point of view it does not matter if they can actually produce
output themselves. It also does not matter how they forward jobs onto a
physical printer. It could be IPP or it could be a simple protocol such
as port 9100. The most important thing is that it doesn't matter if the
Queue is "THE" implementation of the Cloud Print Provider or simply a
protocol gateway to it. From a protocol point of view you can't tell
the difference. The most flexible implementation is that the Queue is a
protocol Gateway to the Cloud Print Provider. Other Gateways can be
implemented to allow an implementation to service multiple Cloud Print
services (i.e., Cloud Print from vendors with their own protocol
binding).
The reason I have worked on the Semantic Model and the Print Job Ticket
I want to get agreement across the industry on the semantics of
Services, Jobs and Documents. With a common model for state transitions
and the semantics of the elements that comprise a Job Ticket it
simplifies the Gateways necessary to integrate with a Cloud Print
Provider implementation. It allows a protocol binding to be IPP,
WS-Print, Google Cloud Print, or some vendor's REST binding. My
preference would be a Web Service binding of IPP but since there is no
existing standard or deployed base I'll go with IPP. IPP has the common
model for state transitions and Job Ticket that has a demonstrated
scalability from a dongle that hangs off a parallel port up to full
production class printers. While IPP semantics is used in many
environments I still see a bit of a gap between protocol centric and
driver centric views in printing.
IPP has most everything we need for a Cloud Print protocol. One thing
that is missing is a mechanism to traverse a firewall. My model is not
a pull-model. My initial implementation was pull-model only to get
around the limitations of printing to a printer behind a firewall. I
viewed moving to a push model as an optimization to be done in a later
iteration. I do not advocate a pull model in a real world
implementation. I don't disallow it either. It seemed to me upon
Printer initialization the Printer would not wait for a signal from the
Queue to begin processing jobs. Getting the available work would be
part of the startup synchronization. To solve the firewall issue I
believe we will need a partial IPP binding to a protocol such as XMPP.
I would think XMPP can be used to deliver events in through a firewall.
Some IPP operations might be needed (e.g. GetJobs, GetPrinterAttributes)
to allow a Queue to synchronize with the Printer on startup.
You were concerned that low end physical printers may have no concept of
a job. The low end physical printer that have no concept of a job and
no support for IPP, or a cloud print protocol, are not within the domain
of this discussion. In order for those types of printers to participate
they need to have a front end (Cloud Print Manager in the functional
model) that interacts with the Queue (Cloud Print Provider in the
functional model). If low end printers wish to embed the Cloud Print
Manager it need only support a list of jobs 1 deep (i.e. the current
job) and only allow a single document jobs. I agree that one of the
advantages of Cloud Print is that all of the "printing smarts" (jobs,
driver, transform, rendering, etc.) can actually be in the cloud based
Print Service Provider (aka Queue). That intelligence may also reside
in the Cloud Print Manager (aka Printer). Note that this need not be
collocated with the physical printer. The Cloud Print Manager could be
communicating with the physical printer via port 9100 and maybe SNMP.
The IPP model accommodates this variation in architecture quite nicely.
I did not quite follow your fan-in/fan-out being "behind the scenes".
My reason for mentioning it is the flexibility it allows for
implementations and deployments. It is easily supported within the IPP
protocol model. I think we are in agreement when you discuss the Print
Manager creating instances of Print Protocol front-ends. This Port
Mapper like functionality is certainly possible. However, as previously
stated, from a protocol point of view you cannot tell the difference
between that and a monolithic implementation. The network behavior is
the same.
You did not understand my concept of "locking the job". I am assuming
the possibility of cluster printing. If it is one Printer per Queue
than this is almost a noop. The Job could move from the 'Pending' to
'Processing' state on this call. It also is the point at which the job
mapping is known to both sides. The operation is needed to allow for
flexibility of system wide job scheduling. While it is true that a
Cloud Print Provider may have the intelligence necessary to schedule
jobs to the appropriate Printer based on current configuration. It is
also possible a group of jobs could be given to a number of printers
allowing a long job or printer fault not to block the Queue.
Finally, I agree that is registration is not just about the printer; but
about the User and the printer. I would go a little farther and include
the printer identity as a "user" and access control that specifies what
Users may put jobs into a Queue and what Printers may process jobs in a
Queue.
Pete
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
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Thursday, December 15, 2011 8:56 AM
To: Zehler, Peter
Cc: cloud at pwg.org
Subject: RE: [Cloud] Cloud Print binding to IPP
Peter
While I understand your model and I failed to understand, as was pointed
out to me, that it represented the more generic case. Therefore, I must
revoke my comments and will refrain from others.
Glen
--
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/20111216/1b31f994/attachment-0002.html>