Hi Bill,
Two replies.
Idle event?
--------------
We already support in the current draft ALL event
triggers from PrtAlertCodeTC (source of SM20 type
SubunitEventWKV), per your comments during the
last PWG face-to-face.
For the very special CONDITION (but NOT event) that
the system is idle, I added the PolicyIntervalPredicate
in yesterday's draft.
This can only be applied to the Interval (periodic)
policy type (e.g., Standby after 300 seconds of idle)
- see the comprehensive examples I added in the
current draft (using every policy group), at your
request.
Too many required power properties?
-----------------------------------------------
By very strong consensus in August PWG face-to-face,
I raised one group (PowerLog) to required in my previous
late August draft.
By strong consensus in the last 2 PWG face-to-faces,
the 3 groups PowerMonitor, PowerMode (supported
states), and PowerTransition (supported transitions)
have been required ever since my first draft.
I could certainly see making PowerLog optional again
(although that's pretty unfriendly to fleet management).
But it's impossible to have any interoperability if either
PowerMode or PowerTransition groups are reduced to
optional.
Not counting PowerLog, there are only 10 required
properties (plus 4 integer keys) in the current spec.
The most powerful group in the model, PowerPolicy
contains half the properties in the whole model and
is optional (and likely to remain so).
Cheers,
- Ira
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
On Wed, Sep 9, 2009 at 4:09 PM, William Wagner<wamwagner at comcast.net> wrote:
> Certainly an interesting idea, and I suspect that there may be other event
> driven triggers that have some appeal. Perhaps we might want to include some
> way of providing for optional triggers, and defining these triggers, so that
> they would remain within the standard management structure rather than a
> proprietary one. The counter-argument says that, unless the printer is
> essentially offline, an incoming job normally is a trigger and these other
> event driven triggers are unnecessary.
>> Comments I received on the previous draft suggest that too much is
> mandatory. Indeed, they asked if this effort was only intended for high-end
> devices. I think, if we are to get good adherence, we need to keep the
> mandatory elements to the minimum. Perhaps it might be necessary to identify
> multiple levels of support rather than make elements optional, so that a
> "level" value gives a true statement of what elements are supported.
>> Bill Wagner
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.