Mike,
Thanks for the update. I was reviewing the diagram again and I had
noted there was no actual print entity "in the cloud"; that is, as an
SAAS in cloud terminology; so adding the Cloud Print Service at least
provides a cloud print SAAS.
Some more discussion ----------
I am still having a problem with the use of a Cloud Print Manager (in
the printer) concept (an the name) in the general context of being a
cloud citizen and with associating a User with an individual Print
Service (Printers). That is, it is not modeled from User's, use-case or
Cloud Provider developers' point of view. As currently defined, the
current Cloud Print Manager is an artifact of a particular
implementation (like DocuPrint; maybe even CUPS) for a fan out with a
single controller (Print Servcie?); from a reference model or
architecture point of view it should not matter if there is such an
entity providing this function. This means your simple diagram reduces
to
Cloud Print Provider
Client <---> Cloud Print Service <---> Printer
With """"""maybe""""" the Printer = [ Cloud Print Manager <--->
Printer(s) ] as seen from Cloud Print Provider
Actually, I see no reason to add the Print qualifier to the Provider;
that is,
Cloud Provider
Client <---> Cloud Print Service <---> Printer
This model states that a Client, as a proxy for the User, can access a
Print Service, of the User's Cloud Provider, to print to a User's
register print device.
This model can be used to represent several different solutions or
implementations:
1. The "Cloud Provider" is Print Cloud (like HP's or Epson's or)
Print Cloud Provider
Client <---> Cloud Print Service <---> Printer
a. A good and bad model - requires other Cloud Solution to
federate with Print Cloud Provider. This would be a big development
effort for print vendors.
2. Cloud Print Services are integrated into a Cloud Provider like
Google Cloud
Cloud Provider
Client <---> Cloud Print Service <---> Printer
a. Again, good and bad. Good for print vendor in that the
Cloud Provider manages Print Service; bad for the same reason.
3. The Cloud Print Service is a "mini-cloud" or a "plug-in cloud"
(but still in the Cloud) that is callable by a Cloud Provider.
Cloud Provider
Client <---> \ \
\ \
\ Cloud Print Service <---> Printer
Where there is cloud around both Cloud Print and Cloud Print Service
a. Yes, this looks like model in the current specification
but with some slight differences.
i.
The Cloud Print Services are in the cloud; thus, they are cloud SAAS
1. Yes, the Print Service could be in the physical printer but
virtually linked ("registered") in the Cloud
ii. A
printer is associated with a single Cloud Print Service
1. From the User's and the Cloud Provider's point-of-view, one
Print Service is associated with one Printer. The User and Cloud
Provider developers never know about fan-out, fin-in, fan-up, fan-down
or any kind of fan; they know there an associated Print Services for a
specific Printer.
a. Internally, an individual "Print Service" can support 2,
700,039 Printers; that is something the print vendor does as part of
their implementation detail. It will not affect the API's the Cloud
Provider developers uses to print to the printer. And has nothing to do
with the PWG Cloud Print specification.
2. From the User's and the Cloud Provider's point-of-view, one
Print Service (associated with one Printer) has its own queue.
a. If a print vendor wants to have individual queues (the "bucket"
of Print Jobs) for each printer or have one giant queue (a big "bucket")
that individual printers pull jobs from, this again, is a print vendor
implementation detail. And has nothing to do with the PWG Cloud Print
specification.
iii.
From the Cloud Provider's point-of-view, the above definitions makes all
Cloud Print Service interfaces look the same; that it,
1. An individual Printer is registered and has an associated a
single Print Service
2. The Cloud Provider only talks to the Printer's Print Service for
all APIs and actions.
3. Print Jobs are submitted to the Print Service for the target
printer (no matter how the queue is implemented)
iv.
Thus, the goal of the PWG Cloud activity is to define the API's and data
for the Cloud Provider to/from a Cloud Print Service
1. I know - use IPP
a. I don't think IPP will be used by everyone. (Who is using it
now for Cloud?) What "will be used" is the PWG:PJT, which does not
require IPP to be useful. PWG:PJT make federation of the Print Jobs
very simple. In general PWG:PJT is a perfect candidate for cloud print.
So the final model is something like
Cloud Provider |-------
a Directory/Registry of Vendor Print Clouds
Client <---> \ \ < -------------------- register
Printers (and its Print Service) to a User
\ \
\ Vendor M Print Cloud
\ Vendor N Print Cloud
Print Service <--->
Printer Print Service <--->
Printer
Print Service <--->
Printer Print Service <--->
Printer
Print Service <--->
Printer Print Service <--->
Printer
Print Service <--->
Printer Print Service <--->
Printer
Print Service <--->
Printer Print Service <--->
Printer
Print Service <--->
Printer Print Service <--->
Printer
glen
________________________________
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Friday, April 06, 2012 9:00 AM
To: Petrie, Glen
Cc: Peter Zehler; Ira Mcdonald; ipp at pwg.org; cloud at pwg.org
Subject: Re: [IPP] Where is the Cloud Print Manager in the PWG: Cloud
Model
[Adding cloud at pwg.org since this is a cloud discussion]
Glen,
In the original BOF-generated functional model, the Cloud Print Manager
is either located in the Printer or attached to the Printer (e.g. in the
local print server). The Cloud Print Manager manages communications
between the lower-level printer interface and the Cloud Print Provider.
Based on our last telecon, we have introduced a Cloud Print Service into
the model which is the service in/under the Cloud Print Provider (which
acts as a System Control Service in the Semantic Model sense) that
manages the jobs/queue in the cloud for the Cloud Print Manager. The
rough ASCII art diagram in my mind looks like this:
Cloud Print Provider
Client <---> Cloud Print Service <---> Cloud Print Manager <--->
Printer(s)
Thus, Clients and Cloud Print Managers talk directly to the Cloud Print
Provider and corresponding Cloud Print Service, but never directly to
each other, and only the Cloud Print Manager actually talks directly
with the Printer(s) (physical or logical) it is registering/sharing with
the Cloud Print Provider/Service.
There can potentially be multiple logical or physical printers behind
the Cloud Print Manager (think traditional fan-out configurations and
reprographic services) and those printers *may* be addressable using the
IPP/SM output device attributes/elements, but there is only a single
Cloud Print Service per Cloud Print Manager and to the Client it will
appear to be a single "queue" with one or more output devices associated
with it.
On Apr 6, 2012, at 8:34 AM, "Petrie, Glen" <glen.petrie at eitc.epson.com>
wrote:
Ira, Pete,
I believe it was stated in the last conference call that the Cloud Print
Manager in the cloud model diagram "is not in the cloud". Is this
true? If so, where is it "located"?
Glen
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean. _______________________________________________
ipp mailing list
ipp at pwg.org <mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
<https://www.pwg.org/mailman/listinfo/ipp>
__________________________________________________
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/20120406/0e8ff469/attachment-0002.html>