Ira Mcdonald wrote:
>But you still DO poll sometimes. There are well over a hundred
>job attributes defined (and probably more coming). Binding them
>all into larger and larger notifications which are UNRELIABLE
>ANYWAY (for delivery) isn't good design.
I totally agree that not everything can be passed, but believe that these three
(or most importantly, job-impressions) are very important to active job
monitoring.
>The issue of when certain 'static' variables getting initialized
>is specific to each interpreter and each implementation. A client
>always want correct information immediately available. But servers
>fill it in when they know it (perhaps quite a way into the job,
>including at the END of the job - which defeats a 'gas gauge'
>entirely).
It is funny how we use the same arguments for opposing conclusions! Your point
is exactly the reason why I think the value has to be added to notifications: if
there is no way for the monitoring application to know when the value will be
set, or even *if* the value will be set, it is unreasonable to expect the
application to poll for the information. In the worst case, the poor app polls
for this information on every job, and never once in its miserable life does it
actually even find out one piece of "total" information because the printer it
is polling doesn't set those values.
With the current notification content, if I had to write an IPP monitoring app,
I would give up on either gas gauges or notifications. Trying to do both is
much too complex: waiting on notifications while simultaneously doing frequent
polling just doesn't seem right (if a gas gauge is considered important, the
polling for the "total" information really should be frequent).
Dennis