Randy,
Since the proposed interface already provides a composite view of the subunit state/configuration reported by the Cloud Imaging Manager, I don't think it would be a stretch to have the Cloud Imaging Control Service report the roll-up view, much like the SM System Control Service already does.
But definitely #4 is out of scope for this round...
On 2013-04-30, at 2:39 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>> Hi Mike (and everyone else)
>> I think the main advantages to your approach are #1 and #2 -- to preserve simplicity, I would defer #3 and #4 -- I think the imaging provider should be kept as simple as possibly, with as much device complexity probably isolated to the manager portion of our model (or basically as far down our model hierarchy as possible)
>> Randy
>> On Apr 30, 2013, at 4:57 AM, Michael Sweet <msweet at apple.com> wrote:
>>> All,
>>>> At yesterday's conference call we talked about the Cloud Imaging Service as a front-end or "meta" service that provided a coherent view of all MFD services registered with a Cloud Imaging Manager/Imaging Device. This service necessarily would need to be able to report all of the service endpoints, names, and types so that a Client or Cloud Imaging Manager would know which services were provided/registered and where, very much like the SM System Control Service.
>>>> I've been thinking some more about that and I think the Cloud Imaging Service *is* basically a SM System Control Service with additions to support the interface with the Cloud Imaging Manager. There are several advantages to this approach:
>>>> 1. A System Control Service provides operations for creating new services, providing a way for us to define registration of new Cloud Imaging Managers/Imaging Devices with the Cloud Provider, something that we had previously tabled as out-of-scope. IMHO, this makes for a much more compelling model that has a chance of basic interoperability from the initial configuration of the Imaging Device.
>>>> 2. A System Control Service provides a common interface for Clients to enumerate the available services they are interested in, vs. using a different interface depending on whether Cloud or local devices were being accessed.
>>>> 3. A System Control Service provides a view of all subunits managed by its services; this opens up some interesting managed service options that would otherwise need to be handled through other, proprietary means
>>>> 4. A System Control Service would allow us to address remote management of Imaging Devices (vs. services), although I believe we should still keep this out-of-scope for the 1.0 document.
>>>> In addition to the Cloud Imaging Manager operations, there are a number of additions I think we should make to the existing SM interface as well, which would affect *all* SM services:
>>>> 1. Provide a way to get Imaging Device specific elements; in IPPSIX this is the new Get-Output-Device-Attributes, which returns the Printer attributes associated with a given device UUID - this is the converse of the Set-Output-Device-Attributes operation that is sent by the Manager to update/set the current configuration/capabilities of the device.
>>>> 2. Add elements to enumerate the Imaging Devices associated with a service; for IPPSIX I just added parallel attributes called device-uuid, device-uuid-assigned, and device-uuid-supported.
>>>> 3. Add elements to the Job and Document status groups that show the state on the Imaging Device assigned to that Job or Document. In IPPSIX these are the output-device-document-state, output-device-document-state-message, output-device-document-state-reasons, output-device-job-state, output-device-job-state-message, and output-device-job-state-reasons attributes.
>>>> All of the new Imaging Device elements and operations would probably remain optional for non-Cloud usage (implementations/administrators get to choose whether this information is exposed, just as in SM 1.0), but for Cloud I think we have to expose it in order to support the Cloud Imaging Service - Cloud Imaging Manager interface.
>>>> Finally, if the Cloud Imaging Service *is* a superset of the SM System Control Service, it might make sense to change the name to Cloud Imaging Control Service. That would express the hierarchy and heritage in (hopefully) a less confusing way:
>>>>>> Client -------> Cloud Imaging Control Service
>> | |
>> +----------> +------ Cloud Print Service -\
>> | +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> \ +------ Cloud Scan Service --/
>> \ |
>> \ +------ Cloud Print Service -\
>> \-------> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> +------ Cloud Scan Service --/
>> |
>> ...
>> |
>> +------ Cloud Print Service -\
>> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> +------ Cloud Scan Service --/
>>>> Thoughts?
>>>> _________________________________________________________
>> 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.
>> _______________________________________________
>> 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.
> _______________________________________________
> 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, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130430/7d44ffe8/attachment-0002.html>