Jay,
No, I don't think this new object will be difficult or costly to
implement for Xerox or anyone else. In general I always take an
opposing position to adding new objects. I do this mainly to guarantee
that a real need exists. In this case it is now apparent from the
various vendor responses that the object is neccessary.
I am concerned with Gail's response though:
"Warnings/informationals include, but are not limited to, changes in paper
level, changes in media weight, color, type and form parts for a tray(happens
whenever a tray is removed or inserted, can't remember), tray remove/insert,
addition/deletion of a paper tray or duplexor. Almost anything that can happen
goes into the alert table."
Was it really intended that the alert table be flooded with
informational alerts which are not really critical to printer management?
Thanks,
Angelo
----------
From: JK Martin
To: Angelo Caruso at wb.xerox
Cc: pwg at pwg.org
Subject: RE: Draft of the new prtAlertTableChanges MIB object
Date: Tuesday, August 06, 1996 6:14PM
Angelo,
> I would like to propose the following alternative to the new
> prtAlertTableChanges object. This alternative requires no new objects
> and is fairly simple to implement.
I like your approach to solving the problem without having to add
another MIB object. However, considering the responses from some
of the other printer vendors, we're back to the situation where
a mgmt app needs a simple, low-cost (for both the app *and* the
printer!) method to determine if at least a change has been made
to the Alert Table to the addition/removal of a critical alert.
Binnur sums it up pretty well with:
> I have talked to few people around here.. The feeling is that the number
> of alerts generated is printer implementation depended.. It could range
> from an almost stream to only a few alerts.. So, the engineers around
> here would like to have some what deterministic way of picking up new
> alerts.. They feel implementing a counter that gets incremented every
> time a warning or critical error occurs would be satisfactory..
Angelo, does this extra MIB object present Xerox with a major problem
(other than adding yet another MIB object)?
...jay