Ira,
Certainly a significant simplification. Thank you. We will see what the
response is.
Question: You state:
delete PowerStateMessage from PowerLog (redundant w/ PowerMonitor)
and
delete PowerStateMessage from PowerMode (redundant w/ PowerLog)
I am not sure of your intent (nor perhaps of several other things)
With regard to PowerStateMessage, is this just a localized string defining
the current power state and for which there is just one message per
enumerated power state? That is, is it just a manufacturer specified name
for the enumerated power state? I wonder at the example given in 5.3.1,
where the PowerOn state has a message of "Ready". I would expect that you
may have a PowerOn state where, because of no paper for example, the device
is not Ready.
If PowerMode is a table of all power states supported by the device (these
seems the case since it is a table under capabilities, although this is not
specifically stated) and PowerStateMessage is a manufacturer determined
localized Power State Name, it might reasonable to provide the enum/name
information in PowerMode. If PowerStateMessage for each powerstate may be
one of several messages providing additional information about the power
state, or how the device got there, or that it was someplace in the timeout
going to a different power state, or whatever, then it may be more difficult
to provide an enum to message set entry.
Thanks,
Bill Wagner
-----Original Message-----
From: wims-bounces at pwg.org [mailto:wims-bounces at pwg.org] On Behalf Of Ira
McDonald
Sent: Wednesday, September 23, 2009 1:34 PM
To: wims at pwg.org; Ira McDonald
Subject: [WIMS] URGENT - simpler Power classes - please reply ASAP
Hi, Wednesday (23 September 2009)
For review at our next WIMS WG teleconference on Monday (28 September).
Below are some simplifications for my next draft of Power Management
Model - please read and reply ASAP - thanks.
New conformance packages are TBD, after further discussion.
FAIR WARNING - In the absence of any protests, I will make ALL of these
changes in my next draft of Power Management Model (except perhaps the
PowerPolicy breakdown into 3 new simpler policy groups).
PowerMonitor (REQUIRED)
- keep PowerState (single-access read of state is a base requirement)
- keep PowerStateMessage (only localized state message - see below)
- delete MonitorID (only one instance allowed per System/Subunit object)
- delete PowerStateTimestamp (redundant w/ PowerLog)
- delete LastLogID (not useful, per Mike Fenelon)
PowerLog (OPTIONAL)
- keep LogID (key)
- keep PowerState and PowerStateTimestamp (machine-readable)
- delete PowerStateMessage (redundant w/ PowerMonitor)
- delete LogPolicyID (not useful, per Ira)
PowerMode (OPTIONAL)
- keep PowerState (key)
- keep PowerUsageWatts (per Power Mgmt Project charter)
- keep IsAcceptingJobs, IsProcessingJobs, IsValidRequestPowerState
(per Power Mgmt Project charter - but rename for clarity)
- delete PowerStateMessage (redundant w/ PowerLog)
PowerTransition (OPTIONAL)
- keep StatePowerState and EndPowerState (keys)
- keep StateChangeSeconds (per Power Mgmt Project charter)
PowerPolicy (OPTIONAL)
- maybe divide up into 3 simpler policy groups (see below)
- delete PolicyTotalTriggers (overkill, though CIM supported)
- delete PolicyLastTriggerTimestamp (overkill, though CIM supported)
PowerRequest (OPTIONAL)
- keep RequestPowerState (read-write)
- keep RequestStatus (machine-readable)
- keep RequestStatusMessage (human-readable status message)
- delete RequestID (only one instance allowed per System/Subunit object)
- delete StartRequestTimestamp, EndRequestTimestamp (see PowerLog)
NEW - possible breakdown of PowerPolicy for simpler implementations
PowerTimeout (OPTIONAL)
- TimeoutID (key)
- TimeoutRequestPowerState (requested new state on timeout trigger)
- TimeoutStartPowerState (optional starting state, e.g., 'On')
- TimeoutPredicate (for activity versus inactivity)
- TimeoutSeconds (actual interval)
PowerCalendar (OPTIONAL)
- CalendarID (key)
- CalendarRequestPowerState (requested new state on calendar trigger)
- CalendarIsOnetime (recurring versus one-time calendar triggers)
- CalendarWeekday
- CalendarMonth
- CalendarDay
- CalendarHour
- CalendarMinute
PowerEvent (OPTIONAL)
- EventID (key)
- EventRequestPowerState (requested new state on event trigger)
- EventName (trigger event name)
NOTE - DMTF CIM and OASIS standards both depend on IETF Schedule MIB
(along with all IETF System Policy standards), so I'm very strongly
opposed to changing Calendar elements to be incompatible.
Comments?
Cheers,
- Ira (Power Management editor)
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: 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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
wims mailing list
wims at pwg.orghttps://www.pwg.org/mailman/listinfo/wims
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.