[Cloud] Minutes posted from today's Cloud Imaging WG conference call

[Cloud] Minutes posted from today's Cloud Imaging WG conference call

[Cloud] Minutes posted from today's Cloud Imaging WG conference call

William A Wagner wamwagner at comcast.net
Mon Jul 22 16:12:55 UTC 2013


Michael,

 

I think I agree with you, although I do not quite follow all that you write.
The Identify Services operation  informs something in the Cloud (I  think it
is an existing specific  Cloud Imaging System, but I suppose it may be a
generic something) of the Services that are to be registered. The Cloud
entity responds with its supported Cloud Imaging Services, either created in
response to the Proxy operation or preexisting. However, since we agree that
the Cloud Service may be pre-existing, we cannot construct the registration
model on it being created  in response to the registration; nor can we
assume that the elements of the Cloud Service will necessarily correspond
with the elements of a specific Device Service.

 

We have maintained that, in normal operation, the Proxy communicates Print
Service  information to the Cloud Print Service, Scan Service information to
the Cloud Scan Service, etc.  It seems reasonable that in registering a
specific service, the Proxy communicates with the corresponding Cloud
Service.  Therefore, I suggest that the Proxy send Device Service Elements
to the corresponding Cloud Service to register a Device Service. However,
we have some options introduced that may not have been obvious when
considering just a Cloud Print Model.

1.       We are dealing with Imaging Systems, both in the Cloud and in the
Device, not just services.

2.       There can be multiple Imaging Services, including multiple Imaging
Services of the same type, in an Imaging System

3.       There may be elements of a Device Imaging Service as well as
Services in a Device Imaging System that the owner may not wish to make
accessible to the Cloud.

In a trivial case where there is just one Service or all elements of all
services are to be registered with all corresponding Cloud Imaging Services
in a Cloud Imaging System, Owner interaction may be just identifying the
Cloud Imaging system. But the model must allow for the more complex
relationships.

Thanks,

 

Bill Wagner 

 

From: Michael Sweet [mailto:msweet at apple.com] 
Sent: Monday, July 22, 2013 8:59 AM
To: William A Wagner
Cc: 'Randy Turner'; cloud at pwg.org
Subject: Re: [Cloud] Minutes posted from today's Cloud Imaging WG conference
call

 

Bill,

 

On 2013-07-20, at 5:04 PM, William A Wagner <wamwagner at comcast.net> wrote:

Hi Randy,

 

1.       Since it was decided that a Cloud Imaging Service could be
associated with more than one device, we had to model a way to register a
Device service with a pre-existing Cloud Service. There seemed no advantage
in also modeling a mode where registering a device  created the Cloud
imaging service.

 

I don't think we decided that the Cloud Imaging Services were already
created.  But we *did* decide that they might already be created and reused,
so rather than requiring a particular implementation with a new service for
every device, we can simply have an operation that allows the Proxy to
identify which services are available for the Proxy to use.

 

I think it is important to reflect this in the description of the Identify
Services operation - a Cloud provider may do lazy creation (on first
registration) of services in the device owner's account, or might just
create services as part of the creation of the device owner's account.  All
of the details are out-of-scope, all we care is that the services exist (and
are started) by the time the Cloud Imaging Control Service responds to the
Identify Services request from the Proxy, right?

 

_________________________________________________________
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/20130722/3c9341b0/attachment-0002.html>


More information about the cloud mailing list