PMP Mail Archive: Re: Re[4]: PMP> Top 25 minus 4 conditions/alerts proposal

PMP Mail Archive: Re: Re[4]: PMP> Top 25 minus 4 conditions/alerts proposal

Re: Re[4]: PMP> Top 25 minus 4 conditions/alerts proposal

JK Martin (jkm@underscore.com)
Fri, 9 May 1997 14:29:23 -0400 (EDT)

Gail,

> > If a vendor chooses to add two alert entries for the printer-stopping
> > low toner condition, then the offline alert should have its description
> > string clearly state that the reason for going offline is due to the
> > low toner condition, and not simply say "Offline" (as so many do now).
> >
> > Is this a fair compromise?
>
> If we are going to have multiple "types" of offline, then the other variables
> in the alert table probably should reflect the differences. At a minimum the
> offline alert should have different prtAlertLocation's based on the "type" of
> offline. To me a better implementation would have different alert groups and
> alert group indexes as well.

You're absolutely right. Thanks for pointing this out. In the (now infamous)
case of a critical low toner condition, the (single) "Offline" alert would
not only have a description saying "Low toner", but also have the alert
group point to the Marker group, etc.

> This could take a lot of space in an imbedded system where space is precious,
> either code space to create the entry and then ram space to store it or extra
> entries in a table. Additionally this could clutter up the alert table with
> multiple offlines and we should definatly try to hold the size of the table
> down.

I agree, and I thought other printer vendors would agree regarding the
embedded space requirements when multiple alerts are posted for a single
condition. I was hoping this new compromise could be the "best of both
worlds".

> Given that you really want to inform the user of why the printer is not
> printing, I like your previous suggestion better. One alert describes the true
> state imposed by the alert(one alert that is tonerlow, critical and one that is
> tonerlow wraning). This also seems to be more consistent with other critical
> errors. It is annoying that I have two alerts for basically the same engine
> event, but to me, it is cleaner then the above.

Thanks for your support.

...jay