Hi,
For this diagram, I agree with Pete. The System object is tucked away
invisible (sort of)
inside the System Control Service.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, Dec 11, 2013 at 3:13 PM, Zehler, Peter <Peter.Zehler at xerox.com>wrote:
> All,
>> Mike asked “so do you think we could just leave the system object out of
> the diagram then?”. For this diagram my answer would be yes.
>>>> 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:* Michael Sweet [mailto:msweet at apple.com]
> *Sent:* Wednesday, December 11, 2013 11:10 AM
> *To:* Zehler, Peter
> *Cc:* William A Wagner; <cloud at pwg.org>; <ipp at pwg.org>; Semantic Model
> 3.0 Workgroup discussion list
> *Subject:* Re: [IPP] [Cloud] Simplified Cloud Imaging Diagram for a
> typical MFD
>>>> Pete,
>>>> On Dec 11, 2013, at 9:44 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> All,
>>>> The thing that confused me about the diagram was the dotted line from the
> Proxy to the Local System Control Service. It is my view that the Local
> System Control Service is just another service hosted on the MFD. (Yes I
> know that an implementation could host the services outside the MFD but
> from a functional view they are hosted on the MFD.)
>>>> Absolutely, I just wasn't sure whether the proxy needed to talk to the
> local System Control Service...
>>>> One difference I see with a Local System Control Service is that in
> addition to interactions with the Physical Device it would also interact
> with the other hosted services. It must do so in order to control the
> other service and to access the other services instrumented data. The
> other difference between the Local System Control Service and other hosted
> services is that the Local System Control Service would have an unfiltered
> view of the devices subsystems.
>>>> Right, however that interface is going to be a lot different than the
> service-level interfaces shown in the diagram. Perhaps some sort of the
> containing box
>>>> The other devices would have a service specific view of the subsystems
> (e.g., Print Service does not present the scanner subunit). Of course this
> difference would not be obvious from the diagram. While not included in
> this discussion the Physical Device could easily be replaced by a Physical
> Device Proxy and the model hold together.
>>>> Right. Again, my focus with this diagram was just to show the
> typical/common situation. If we can find a way to expand its scope without
> confusing things too much, all the better.
>>>> I would replace the lower portion of Mike’s diagram with something
> similar to the following diagram. I also added a comment to #3 below.
>>>> I'd like to come up with a different way to show the relationship between
> the System Control Service and other services. And maybe that applies to
> the interface between the services and physical device/subunits as well?
> (not a service-level interface and not something we document in the Cloud
> or Semantic Models...)
>>>> ...
>> 1. According to the Semantic Model, there is an extensive client
> interface to the System Control Service that provides access to both System
> Control Service elements and System Object elements (SystemConfiguration,
> SystemDescription, and SystemStatus). However, the diagram shows no System
> Object either at the Cloud Level or the Local level (“Imaging System” in
> the lower right hand corner not withstanding.) The sort of information
> that a User might want to know about the physical location of the “device”
> (however one may wish to define it) is in the System Description. The UUID
> for the imaging device is the System UUID. I suggest that, as in the
> previous diagram, there is both a Cloud Imaging System and, if we are
> showing things beyond the Proxy, a Local Imaging System.
>>>> Adding the system object to the diagram would probably be useful. I'm not
> sure how we would show connections *to* this object, or whether we should
> (for purposes of simplifying the diagram) just update the system control
> service boxes to be "system control service and system object"?
>> <PZ>The System Object is a construct created and maintained by the Local
> System Control Service just as the Print Service Object is created and
> maintained by the Local Print Service. Some of the attributes from the
> System Object are obtained from the Physical Device, other attributes are
> obtained from the other Local Services, and some are properties specific to
> the instance of the Local System Control Service. I do not see any
> conflict in the other Hosted Services presenting information (e.g., System
> UUID, physical location) that is “owned” by the Local System Control
> Service as long as the values are consistent.</PZ>
>>>> OK, so do you think we could just leave the system object out of the
> diagram then?
>>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131211/f1b12d2c/attachment.html>