Bill,
First, I have no real complaints about what you refer to as "editing"
of the Alert Table with respect to unary alerts.
I previously asked Harry Lewis:
If a mgmt app can't trust the Alert Table to contain all
existing problem descriptions (ie, critical alerts), then how
can the Alert Table be useful?
Given, if the mgmt app polls the printer at a fairly high rate,
then perhaps the mgmt app can believe that it won't miss the
insertion of a new alert. But I wouldn't bet money on that
approach.
Can you shed some light on what kinds of problem areas and
scenarios would find the Alert Table useful?
I would now like to ask you the same questions. What problem scenarios
can you suggest that would make good use of an Alert Table that does
not necessarily contain all existing critical alerts?
I'll say in advance that if the answer is something like "well, it can
be used as a 'hint' to a mgmt app...", then I'd have to point out that
we already have other objects to provide such hints, such as the counters
indicating changes to the Alert Table (which, if the Alert Table were
to be removed, would be changed to simply reflect the number of critical
alerts encountered, rather than reflecting changes to the Alert Table).
Bill, please give us your ideas about how the Alert Table can be used
given the current design. We'd really appreciate it.
By the way, have you had any experience in coding a mgmt app to deal
with the Alert Table? Has anyone else in PWG land experienced this
effort?
If the Alert Table were not so critical for our printer mgmt app, I'd
simply smile when you call my comments "hyperbole". However, when we
ask our customers whether it would be OK for us to miss a critical
alert or two, they inevitably remark "Then what good is your
software?" This does not make me smile. Your comments below make it
sound as if it's ok for the mgmt app to miss critical alerts.
Does anyone else out there share Bill's view, that it's ok for a mgmt
app to miss critical alerts? It could be that the answer to this
question will ultimately drive the resolution of this entire issue.
Comments from one and all are definitely appreciated. I would really
like to see some comments from the Lexmark and Tektronix folks, in
particular.
...jay
----- Begin Included Message -----
Date: Fri, 4 Apr 1997 02:09:26 -0500
From: bwagner at digprod.com (Bill Wagner)
Subject: Re[2]: PMP> Alert table thoughts
Cc: pmp at pwg.org
Content-Transfer-Encoding: 7bit
Jay,
I suppose I do regret cutting the last day of interop testing.
1. Although I find Matt's proposal well expressed, and I agree that
it may be desirable to a continuously edit the alert table to ensure
that it fully expresses the current condition, I do not agree with
making the concise editing of the table mandatory. The table
management paragraph recognized that there must be some way to empty
events or else the table would fill up. It defined a simple protocol
(set of rules) to make room. Its intent was not to require that the
printer remove unary events the effect of which appears to have been
superseded by other unary events. I believe it unreasonable to mandate
this.
2. I suggest that Jay is indulging in hyperbole in stating "if the
Alert Table was not mandated as maintaining the complete set of
existing critical alerts, then the Alert Table was useless and should
be removed." Again, although it would be nice to have a complete
profile of the printer condition in the alert table, and higher end
units will want to stress the fact that they have such support, I do
not believe that it should be mandated. To Jay's objection that it
imposes a requirement on the management application to poll the
printer and keep a record of alert events that the printer may drop, I
suggest that it not be mandated that the management app keep this full
record either. If a printer manufacturer decides that a limited depth
alert table is appropriate for his product, that implementation is
still better than if there were no alert table.
In case I an unclear, I see insufficient justification for mandating
either the editing of alert table events so that only current
conditions are reflected, or for mandating that the alert table be
large enough to accommodate all possible, 'significant', contemporary
alerts.
Bill Wagner, DPI
----- End Included Message -----