IPP> MOD - Push back on simplifying Print operation response

IPP> MOD - Push back on simplifying Print operation response

IPP> MOD - Push back on simplifying Print operation response

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu Feb 20 18:26:57 EST 1997


> 
> My concern is that either:
> 
> 1. User friendly implmentations will make additional protocol calls
> to get job and printer status.  That means that each Print operation
> will require three calls, not one.  If we layer on HTTP that means
> a new session startup/teardown for each of the three calls.


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.




> 



More information about the Ipp mailing list