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/20130421/22520c50/attachment-0002.html>