RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

From: Richard_Landau@Dell.com
Date: Thu Apr 19 2007 - 17:08:23 EDT

  • Next message: Whittle, Craig: "WIMS> CIM - Minutes from the April 19, 2007 teleconference posted"

    I was not proposing any analogous property at all, but an empty class
    with only the method to change the state. What I intend is having a
    class to represent the function of the property we don't like. And the
    class has a RequestStateChange() method to effect the function. And the
    enabled-disabled state of the class shows up in the existing
    EnabledState property.
     
    This is the *last* thing I would do to the new model, after adding all
    the other stuff as read-only as we agreed. Or rather, the first thing
    of the new writable model, the pipe cleaner for putting write functions
    on various properties.
     
    We have the capability (pardon the expression) today, at least in the
    model if not in many implementations, to disable console input. If we
    can model the capability in another way that does not expose a dangerous
    writable property, that seems like a good thing.
     
    rick

    ________________________________

    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Thursday, April 19, 2007 15:39
    To: Landau, Richard; wims@pwg.org
    Subject: RE: WIMS> CIM> There is one podssible candidate for
    EnabledLogicalElement

    Hi,
     
    My two cents - NO - no writable properties at all - no state changing
    methods
    defined in any Phase 2 modelling activity - drop this property entirely
    or show
    it as a read-only boolean in CIM_Printer.
     
    Cheers,
    - Ira
     

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    -----Original Message-----
    From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of
    Richard_Landau@Dell.com
    Sent: Thursday, April 19, 2007 1:51 PM
    To: Richard_Landau@Dell.com; wims@pwg.org
    Subject: RE: WIMS> CIM> There is one podssible candidate for
    EnabledLogicalElement

    Actually, I would propose calling the class ConsoleButtons or
    ConsoleInput. The existing function does not disable the lights or text
    display, only input from the buttons.
     
    rick

    ________________________________

    From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of
    Richard_Landau@Dell.com
    Sent: Thursday, April 19, 2007 13:42
    To: wims@pwg.org
    Subject: WIMS> CIM> There is one possible candidate for
    EnabledLogicalElement

    Console. Not ConsoleLights or ConsoleDisplayBuffer, but a class with no
    properties other than state so that it can be enabled and disabled. In
    the voting spreadsheet from eons ago, we all voted
    prtGeneralConsoleDisable as priority A. And there is a comment on it
    that says, "must be implemented as CIM state accessible by
    RequestStateChange() method." Who would have guessed that we had such
    foresight way back then.

    Proposal: When we get to it, we can use this as a pipe cleaner for CIM
    modeling of this writable property. I think it results in an otherwise
    empty class derived directly from EnabledLogicalElement. No new
    properties, just the state properties and RequestStateChange() method
    inherited from the parent.

    Comments?

    rick

    ----------------------
    Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO
    Office
    +1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682

    --
    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.5.446 / Virus Database: 269.5.4/768 - Release Date: 4/19/2007
    5:32 AM
    


    This archive was generated by hypermail 2.1.4 : Thu Apr 19 2007 - 17:08:30 EDT