Hi Mike,
I agree with your observations below.
Except that the Associate Receipt and Register Receipt below
should be simply Associate Response and Register Response
(consistent w/ other PWG SM operations Request/Response).
They are quite different from a JobReceipt (an ornamented
original User's JobTicket w/ actual chosen and defaulted
values per the Job processing <service>).
And in IPP and PWG SM, we're thinking the Subscription-like
paradigm, so the operations are called CreatePrintAssociation
and CreatePrintRegistration (at least that's what Pete and I
have assumed).
We don't use Subscribe as an operation in PWG SM - I don't
think the Cloud abstract operations should be called simply
Associate and Register. They also both should have input
parameters of the lease time for the created object - nothing
is forever...
Cheers,
- Ira
On Mon, May 14, 2012 at 11:22 AM, Michael Sweet <msweet at apple.com> wrote:
> I think Pete is right that we need to show that registration and
> association go to the Cloud Print Provider (CPP), with registration
> creating the Cloud Print Service (CPS) that is associated with the Cloud
> Print Manager (CPM) for the "long term".
>> I'm also now thinking we should show the Cloud Print System Service (CPSS)
> that the client talks to, since that is how we've been talking about the
> CPP in recent meetings. The CPSS may not be the same service that the
> Client sends its Associate request to - Cloud services are much more
> dynamic and a particular user/organization may have specific resources
> assigned/dedicated to them. The common association/registration front-end
> interface directs Clients and CPMs to the appropriate Cloud services
> assigned for their use.
>> In the diagram we should show a receipt being returned by the CPP for
> Associate and Register requests. An Associate Receipt would return
> something like an OAuth2 token with the URI representing the CPSS (probably
> the same as the one used for the Associate request, but possibly a
> different service endpoint specific to the user/resources/geographic
> region), while the Register Receipt is the OAuth2 token along with the URI
> representing the endpoint for the CPS that is the Cloud's queue for the CPM.
>> Thoughts?
>>> On May 14, 2012, at 5:20 AM, "Zehler, Peter" <Peter.Zehler at xerox.com>
> wrote:
>> All,****
>> The main problem I have with the diagram is that it shows a Cloud Print
> Manager registering with the Cloud Print Service instead of the Cloud Print
> Provider. In my (protocol centric) view a upon the receipt of a
> registration request from a Cloud Print Service, or its agent, the Cloud
> Print Provider instantiates a cloud environment specific implementation of
> a Cloud Print Service. The requirements for that implementation are that
> it implements the PWG Print Service interface, exposes the appropriate
> objects and attributes, and externally conforms to the state models
> codified in the PWG model. At a later time the Cloud Print Manager will
> bind to the Cloud Print Service to provide updated status and capability
> information and to process Print Jobs destined for the physical printer(s)
> associated with the Cloud Print Manager. ****
>> I expect the normal cardinality would be one physical device per Cloud
> Print Manager and One Cloud Print Manager per Cloud Print Service. The
> PWG model accommodates both Fan-Out and Fan-In of Printers. This allows a
> Cloud Print Manager to “front end” a number of physical printers. Those
> printers can be collocated (i.e., printer farm) or distributed (e.g.,
> FedEx printer in Google Cloud Print). Alternatively a single physical
> device could be associated with a Cloud Print Manager that registers
> multiple Cloud Print Services. The purpose of such a configuration could
> be to present different capabilities and/or different defaults for each of
> the Cloud Print Services.****
>> The [Print] Client is shown sending an Association request to the Cloud
> Print Provider. Once the association is established and based on the
> policies in place for the associated user, a set of Cloud Print Services
> will be visible to the [Print] Client. The [Print] Client can then
> interact (e.g., query status, query capabilities, submit print jobs) with
> the Cloud Print Service.****
>> 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:* cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] *On Behalf Of
> *larryupthegrove
> *Sent:* Friday, May 11, 2012 7:05 PM
> *To:* cloud at pwg.org> *Subject:* [Cloud] Cloud white board diagram from meeting - converted
> tovisio/pdf****
> ** **
>ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud model representation.vsd****
>ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud model representation.pdf****
> ** **
> Please review and I’ll update drawing before inserting into the cloudmodel
> draft.****
> ** **
> Larry****
> ** **
>> --
> 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. _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>> __________________________________________________
> 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.
>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>
--
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/20120514/a57c7aef/attachment-0002.html>