Dennis,
I will add as an issue for the upcoming meeting and we will process it. It
does make sense to send them if you support them, so you can get a real
thermometer.
Don't you need to know the job-collation-type in order to know whether the
counter is going to go to n times the size or just to the size, where n is
the number of copies?
So do we need to add "job-collation-type" as well?
Thanks,
Tom
-----Original Message-----
From: dcarney at us.ibm.com [mailto:dcarney at us.ibm.com]
Sent: Thursday, October 21, 1999 08:33
To: hastings at cp10.es.xerox.com
Subject: IPP> Proposal for change to notification content
Tom,
Could you please add this proposal to the issue list for the notification
document? Thanks.
Let me know if you have any questions.
Dennis
---------------------- Forwarded by Dennis Carney/Boulder/IBM on 10/21/99
09:04
AM ---------------------------
dcarney at us.ibm.com on 10/06/99 08:28:28 PM
To: ipp at pwg.org
cc:
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:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-alt-990910.pdf)
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 4.3.17.1 O O
27. job-impressions (integer (0:MAX)) mod 4.3.17.2 CR CR
28. job-media-sheets (integer (0:MAX)) mod 4.3.17.3 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?
Dennis Carney
IBM Printing Systems (303)924-0565