Michael,
1. We agree in preferring not to have separate models for different
imaging services. My comment referred to Larry's diagram where he showed
separate Cloud Service entities for the different imaging services. Also, I
think that we are using the word Service in somewhat different ways: the
Cloud<service>Service is an entity that provides <service>, while the
<service> is a set of functions or capabilities defined by the operations
accepted and acted upon. That is, I consider the Cloud<imaging>Service on a
parallel to an MFD (which might perform just one Service and might not
even include an input or output device).
2. Yes, we have not defined Manager to the Client communication.
Indeed, we (or at least I) have not fully considered the scenarios of cloud
services other than printing, or even if such scenarios are reasonable. I
offer the following for consideration and discussion:
a. The distinguishing point of Cloud Imaging is that it uses one or
more Imaging <services> provided in the Cloud, with the resulting security
complications including firewalls, authentication, etc.
b. Print scenarios, as we have shown, involve a client (or client
function) connecting to a Cloud Print Server. Since Print Servers can
communicate with Print Servers, it could also be a Print Server
communication with a Cloud Print Server. The rub comes with Print Servers
communicating with end devices out of the cloud, requiring a Cloud Print
Manager. Although the scenarios reflect the User being remote from the end
device, this separation of User and output is not a necessary condition
c. For Scan, the corresponding scenario would be that the Client
connects to a Cloud Scan Server which then needs to communicate with a
scanner device (or subordinate scan service) co-located with the User, using
a Cloud Scan Manager. The Client specifies the destination of the Scanned
image, which is where the Cloud Scan Server deposits the image. This seems a
contorted path; a functional alternate may be that the User uses a local
Scan Service that then communicates with a storage capability and/or
Resource Service in the Cloud, but this would be Cloud storage or Resource
utilization rather than Cloud Scanning. (see comment [h])
d. Cloud Copy would use the same path as Cloud Scan, except that an
output destination includes a hardcopy device and would allow selection of
printing attributes.
e. Cloud FaxIn offer complications in setting up a Cloud FaxIn service
to accept faxes for a given User. The User (or administrator) will have
set up the Cloud Service to print or store the received faxes. Depending
upon the capabilities of the Cloud Service, there may been to be a manager
for an out-of-cloud print or storage capability
f. Cloud FaxOut follows a path similar to Scan, with the Client
contacting a Cloud Service. The Cloud Service may then rely upon end-device
managers for scan or local repository access.
g. EmailIn and EmailOut follow similar paths to FaxIn and FaxOut.
h. Transform and Resource services operate from client software in
other imaging services and would need considerations of which are in-Cloud
and which are not. As observed, Resource operations are not Job oriented,
although what is stored for Scan, for example, are image files, not job.
Still, although I think the Resource Service is an important one to have in
the Cloud, it is NOT intended as a job output destination and does not even
provide an appropriate Resource Type category.
3. In this set of scenarios, I do not see where Manager to the Client
communication is needed?
4. I think Paul's point of getting workflow consideration active is
very important. The SM so far has avoided formal workflow by allowing
internal links between services and the Resource Service and Transform
Service, and allowing some internal storage and transform capability
within specific imaging services.
5. I do not understand the question "how does the Client provide a
destination URI that is accessible to the Manager?" My understanding is
that the manager interfaces with the Service. The Service gets the
destination from the Client. The Service receives the digital document from
the scan device, probably though a Scan Manager. The service processes the
image and directs it to storage. It is assumed that the client will identify
storage accessible to the Service and to the client. The Scan Job Ticket
may need some additions to address access issues. And we need to provide
some way for the Manager to return the image to the Service. But if the Scan
Service is in the Cloud, I do not see the Scan Manager sending the final
image to the defined destination.
Thanks,
Bill Wagner
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Sunday, April 21, 2013 8:13 PM
To: William A Wagner
Cc: 'larryupthegrove'; cloud at pwg.org
Subject: Re: [Cloud] Cloud Imaging model requirement draft
Bill,
On 2013-04-20, at 1:22 PM, William A Wagner <wamwagner at comcast.net> wrote:
Larry and Michael,
I do not see either the rational or advantage in separating the Cloud
Imaging Service in the model into separate Service entities. The Semantic
Model is constructed on the basis of an MFD, which can support any one or
more of the imaging services. I do not understand why this model does not
hold equally when the path goes via a Cloud based server.
First, I don't want to see separate models.
Second, my point is that what we have modeled thus far allows a Manager to
retrieve/fetch documents submitted by a Client to the Cloud Print Service.
We have not defined the reverse set of operations, namely how to get a
document from the Manager to the Client.
...
An overall Semantic Model document may be divided into common, document
input and document output services in the discussion; that should be
considered in formatting the document. But I question whether the model
itself should be collapsed. With respect to defining a Cloud
Scan/FaxIn/EmailIn service that provides storage, it is unclear why this
is preferable to a Cloud Imaging Service that includes Scan, FaxIn, EmailIn
and Resource functional services (as well as the other Imaging Services).
I brought this up as a likely way forward for implementing the "document
input" services since ALL of them deal with storage URIs (and not attached
documents like the document output services), and since a Client's storage
URI is very likely NOT going to be usable (since the Cloud Service and
Manager will be unable to connect to the Client's storage URI through its
firewall, assuming that the URI resolves to a routable address) we need to
look at how we can deal with document storage. The logical place for that
is in the Cloud Service, since both the Manager and Client are already able
to access it in our model.
_________________________________________________________
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/20130422/1e940eb8/attachment-0002.html>