Folks,
Lets take a look at a potential, hypothetical implementation. Lets say that my
printer has at most 200 things that can go wrong with it, inclunding everything
from toner low, to paper out for all the trays, to printer on fire. I need all
of the information for the 6 prtAlert variables, and I decide to organize this
information into a table in ROM space. Now to actually construct the alert
table I need a linked list with 3 elements, the index id, the index to my table
in the ROM space, and a next pointer. Lets say that these 3 elements take up 4
bytes apeice. So for my implementation I have used, at most, 2400 bytes of RAM,
which is around 2.5k. I can reduce this number further since I know that there
are some alerts that mutually exclusive with other alerts; for example I know
that a tray can be low on paper or out of paper, but never both. In my opinion,
this is well with the noise range for any printer that wants to include 1759
support, including low memory devices.
Gail
On Feb 1, 3:10pm, Bill Wagner wrote:
> Subject: Re[2]: PMP> Should Alerts be replicated???
> Jay,
>> I believe that RFC1759 does allow binary alerts (obviously
> non-critical) to be removed for table maintenance. I think it is
> unreasonable to require that the alert table be large enough to
> contain the maximum number of binary alerts possible within the
> printer implementation. It is my understanding that the definitive
> status of the device is in the rest of the MIB, with the Alert Table
> merely operating as an assist.
>> Bill Wagner, DPI
>>> ______________________________ Reply Separator
_________________________________
> Subject: Re: PMP> Should Alerts be replicated???
> Author: JK Martin <jkm at underscore.com> at Internet
> Date: 2/1/97 1:49 AM
>>> Chris,
>> > I would like a volunteer to draft some language for this that
> > would cover all the critical and non-critical alerts.
>> Ok, I'll bite... ;-)
>> Once a binary alert is placed into the Alert able, it shall remain
> in the Alert Table until the condition for which it was created has
> been cleared.
>> If a unary alert must be removed due to Alert Table space constraints,
> then it shall not be reentered into the Alert Table should space become
> available at a later time. At no time shall any type of alert be
> replicated in the Alert Table.
>> This will require the agent to ensure that it can maintain an Alert
> Table large enough to contain the maximum number of binary alerts
> possible within the printer implementation.
>> ...jay
>> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm at underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>>>-- End of excerpt from Bill Wagner
--
Gail Songer Electronics For Imaging
gail.songer at eng.efi.com 2855 Campus Drive
(415) 286-7235 San Mateo, CA 94403