[IPP] [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

[IPP] [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Ira McDonald blueroofmusic at gmail.com
Wed Dec 11 20:46:31 UTC 2013


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/blueroofmusic
http://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>


More information about the ipp mailing list