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 at sharplabs.com]
Sent: Thursday, April 19, 2007 15:39
To: Landau, Richard; wims at 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 at sharplabs.com
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of
Richard_Landau at Dell.com
Sent: Thursday, April 19, 2007 1:51 PM
To: Richard_Landau at Dell.com; wims at 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 at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of
Richard_Landau at Dell.com
Sent: Thursday, April 19, 2007 13:42
To: wims at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070419/4877ad0c/attachment.html