My assumption is that the GUI from which the Print submission is made is
a different process from the one showing status in most cases. In such an
environment, the Print submission GUI would probably not inform the
job status GUI about the changes. The primary issue is whether a print
submission GUI (or command) would inform the user of the special case
you site below where the printer is stopped and needs attention before it
will resume printing.
You suggest that there would 3 calls, but I have optimized the Get Jobs
operation so that it can request printer status and jobs lists in the
same response.
>
>
> If the printer to which you submitted your job was printing
> another job and the printer needs attention, you will NOT get a
> notification of this problem, even if you specify the
> notification-events=printer-problem, because the printer problem
> event happened BEFORE you submitted your job. So your job
> will sit there until someone else fixes the problem and you
> won't know about it even though you asked to be notified of
> any printer problems!!!
There seem to be two possible solutions to the above problem:
1) If a Printer receives a job with notification-events=printer-problem
and the printer is currently stopped, it sends the most recent critical
event to the job's notification-address. This actually raises the issue
of whether a user's Print Status GUI should be able to indicate interest
in the Printer Status, even when the user has no job's in the queue.
In such a case, the GUI is up to date and doesn't need this new
mechanism.
2) The print request returns a special status, though for HTTP there
is no reasonable special status value, so there would have to be some
other way, such as via a printer-state value, as you suggest.
We should probably discuss this at tomorrow's meeting.
>