Wow, Jay, you don't ask for much... ;-).
>Can someone quickly state why this is needed (or point me to a relevant
>discussion or other posting)? Having such an alert doesn't seem to
>gain anything. I fully understand the desire to have a related trap
>for this kind of event, but do we really need an "Alert Alert"?
Once upon a time...
If you'll recall back in the early MIF/MIB days, I had requested that both
START and END (or leading and trailing if you will) time (ticks) be associated
with EVERY alert ("unary" alerts would have equal start/stop times). There
was opposition - largely because my proposal came at a time when we had nearly
"locked" the printer MIB. Compromise resulted in the current (optional)
prtAlertTime.
Later... the desire to distinguish the temporal aspect of alerts took hold with
more PWG members. Several proposals were "batted" around, including
re-introduction of my Start/Stop tick idea. I think the main flaw in my
proposal was that that RFC1759 REQUIRES a trailing binary be removed, so how
can you "poll" to find out the end time. (I could be glossing over some other
condition of my or other proposals which made them undesirable).
Anyway... we agreed, en-mass, that we wanted to know WHEN the trap had been
removed and we needed a somewhat persistent entry to carry that information.
Enter the Alert Alert... a UNARY event that would indicate the END tick of a
vanishing binary (sounds almost astronomical!).
By the way... having gone through the recall on this... it might answer an
earlier question... "what made prtAlertTime go from optional to mandatory".
I do believe, it was just about at this point that we realized, if AlertAlert
was to be useful, prtAlertTime would have to become mandatory and there were
few (if any) objections.
>What I *do* recall is that we were going to add two new objects to the
>MIB that functioned in a relatively indentical manner--both syntactically
>and semantically--as the prtGeneralConfigChanges object. One of the
>new objects (prtGeneralAllEvents) would count all changes made to the
>alert table, while the other (prtGeneralCriticalEvents) would only
>count those changes made for critical alerts.
>The philosophy was, as I recall, centered around the idiom whereby a mgmt
>app would only have to watch for changes in one of these new objects in
>order to know whether the app has to process the alert table.
Yup.. all that too. But none of this addresses WHEN DID the alert EXPIRE.
>I realize the draft claims that this new "alertRemovalOfBinaryChangeEntry"
>alert is optional, but still--who is going to use it, and how, and why?
>Could it be that the presence of this alert would result in an app not
>having to parse the entire alert table in order to fully maintain its
>internal working copy?
This is kinda why I asked the question about the "contents" of the AlertAlert.
Unless it points to a specific alert that was removed, what good is it?
Will we use it? I think so. But I think there are a few ramifications that
should be understood like:
1. The use of AlertAlert will result in alert tables that "run full" rather
than "empty" as I suspect is the case today. By this I mean there aren't
many unary's around today and binarys come and go (by definition) so, if
there's any "size" to the alert table it will tend to run sparse. But, if
there is a Unary for every trailing binary, the table will tend to "fill up"
with AlertAlert's. I don't know that it matters... it's just an
observation.
2. Unary AlertAlerts should probably be the first to go among Unary's
if and when room is needed in the table. They're most likely to be
hanging in long after the information they represent is meaningful.
>That seems conceivable, however, since this new alert is OPTIONAL, our
>products certainly wouldn't use it. Our customers expect our products
>to work with ANY "RFC 1759" printer; the overhead and complexity of
>having two algorithms just doesn't pan out, so we always opt for the
>algorithm that is bullet-proof and works across the board.
I hear ya. You're no different than any software in that sense (ooh... was that
a fopa ;-). But, remember, if AlertAlert's are supported, you can find out
about the end time if not, you basically can't. I think that's a bit different
than you code has to determine something one way for 90% and another for 10%.
Right? I don't really have a problem with making it mandatory, however.
Harry Lewis