So zero mean "I don't know"?
* Don Wright don at lexmark.com *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
dcarney%us.ibm.com at interlock.lexmark.com on 10/06/99 10:28:28 PM
To: ipp%pwg.org at interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: IPP> Proposal for change to notification content
Here is the proposal that was promised at the September PWG meeting in Denver.
(I'm not sure which version of the Notification spec I should be using, so I'll
use the one that looks the most recent to me:
I am proposing adding three new rows to table 5 in section "7.3 Additional
Notification content attributes for Job event only". This is being done so
that a monitoring application can present a "gas gauge" showing progress of the
job. To show a gas gauge, the application needs to know *both* the "total" (in
our case, for example, the total number of impressions that will print for the
job) and the "progress" (the number of impressions printed so far) information.
Showing such a gas gauge is not possible using the current notification content,
unless the monitoring application were to query (poll) for the "total" value.
Specifically, the three new rows that would be added:
26. job-k-octets (integer (0:MAX)) mod 126.96.36.199 O O
27. job-impressions (integer (0:MAX)) mod 188.8.131.52 CR CR
28. job-media-sheets (integer (0:MAX)) mod 184.108.40.206 CR CR
These attributes are the "total" values corresponding to the "progress" values
stored in the three attributes shown in rows 18, 19, and 20 of table 5
(job-k-octets-processed, job-impressions-completed, job-media-sheets-completed).
As far as I can see, the main objection to this proposal comes from people who
say "But the number of impressions that are going to print doesn't change as the
job progresses, so why should we pass the same old information on every single
notification?" My answer: au contraire--the values *do* change! As described
in the model document, the printer may set these values when it knows them.
That is, when the printer determines the number of impressions that are going to
print, it will set the job-impressions attribute. That might happen before the
first page prints (contrary to some people's belief, I see this all the time,
even on 20+ page jobs (but not on pdf jobs :-) ), it might happen 5 pages in, 15
pages in, or 2 pages before the last page prints. In any case, the monitoring
application can not know ahead of time when this information will be available,
so if it really wants to present a gas gauge, it has to wait for notifications
for "progress" values, but *constantly poll* for "total" values! If it's
polling for the "total" values, it might decide to just grab the "progress"
values while it's at it and forget about notifications altogether.
Note that these values need to be passed on 'job-completed' notifications as
well, because the monitoring application would like to know how far the job got.
For example, if the job was canceled, it is useful to know that 22 of 24 pages
printed as opposed to 22 of 444 pages. Also, on printers that do not set the
"total" value when they know it, there is no guarantee that the "total" value
matches the "progress" value even on jobs that completed, and this might be of
interest to a monitoring application: if it sees a job that was thought by the
sender to be a 14 page job but 47 pages printed, it might want to throw up some
sort of warning that the job might not have printed correctly. Note also that
there is only one 'job-completed' notification per job, so passing more
information than might be necessary in some cases is not too costly (these
values are all simple integers in any case, so they take up little room).
Remember that some notification recipients might request 'job-completed'
notifications and not 'job-progress' notifications.
Comments, counter-proposals, questions anyone?
IBM Printing Systems (303)924-0565