Hi,
I strongly urge that we keep the first class object Cloud
Print Manager in the functional model. How the CPM
communicates with actual Print Devices (Printers) is
now and SHOULD remain completely out-of-scope.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Fri, Apr 6, 2012 at 4:19 PM, larryupthegrove <larryupthegrove at comcast.net
> wrote:
> Glen,****
>> ** **
>> I’m struggling with a number of statements, I agree the connection between
> the user and the cloud is one part of the model, and the other part is the
> connection of the cloud to a logical print something or other (within my
> system). Since the model started as an imaging model, I believe the cloud
> to print connection should also be usable for a scan to cloud, with
> different elements.****
>> ** **
>> As a user and implementer I’m focusing on where the connection to the
> cloud originates, and where the connection from the cloud is terminates.**
> **
>> ** **
>> So where you have in the last drawing – Vendor M and Vendor N, are those
> print services from different print vendors or?****
>> ** **
>> Larry****
>> ** **
>> *From:* cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] *On Behalf
> Of *Petrie, Glen
> *Sent:* Friday, April 06, 2012 10:35 AM
> *To:* Michael Sweet
> *Cc:* ipp at pwg.org; cloud at pwg.org> *Subject:* [Cloud] RE: [IPP] Where is the Cloud Print Manager in the PWG:
> Cloud Model****
>> ** **
>> 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****
>> 1. 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. ****
>> ** **
>> ** **
>> ** **
>> 1. Cloud Print Services are integrated into a Cloud Provider like
> Google Cloud****
>> Cloud Provider****
>> Client <---> Cloud Print Service <---> Printer****
>> 1. Again, good and bad. Good for print vendor in that the Cloud
> Provider manages Print Service; bad for the same reason.****
>> ** **
>> ** **
>> ** **
>> 1. 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****
>> ** **
>> 1. 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>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* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>> --
> 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>https://www.pwg.org/mailman/listinfo/ipp>>
--
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/ipp/attachments/20120407/d1ddf028/attachment-0001.html>