IPP Mail Archive: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:

RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 2 Jun 1997 18:09:21 PDT

At 04:57 05/28/97 PDT, Peter Zehler wrote:
>Tom,
>The amount of time a job would be in the pending state on a non-queueing
> non-spooling printer could be noticable to humans. It is dependant on the
>size of the print jobs on the other channels.

Then such a printer shall implement the conditionally mandatory
pending state. But an implementation that never waited a human perceptible
time should not have to implement the 'pending' state. Imagine that you
are building a product that is going to be tested against by a testing
company. If 'pending' is mandatory and your product doesn't ever show
'pending', that testing company might say you didn't conform to the
standard.

>I think it would simplify things just to have the pending state mandatory.
>Implementations could step through this state so quickly it would never be
>noticable to humans.

If we spend much more time discussing this issue, it may be wiser to take
your suggestion and make 'pending' mandatory.

>Pete
>
>
>Peter,
>
>How long would a job be in the pending state in your non-queuing, non-spooling
>IPP system?
>
>If the time is not noticable to humans, e.g., 100s of miliseconds, I would
>think that there wan't much point in simplementin the IPP state of 'pending'.
>If it was longer, so that end-users would see it for a while, while nothing
>was happending on the printer, then it would be good to implemente the
>IPP 'pending' state for your Printer object.
>
>So your point was not that 'pending' must be a Mandatory state, but
>that in your implementation of a simple, non-queuing, non-spooling printer
>you wanted to be able to implement 'pending'. So we just have to find
>language that permits non-queuing, non-spooling printers to implement
>'pending', but doesn't require it.
>
>On the other hand, it might be simpler to mandate the 'pending' state
>and for implementations that don't queue or spool, the state would
>never be visible or would be visible for a very short period of time.
>
>Tom
>
>
>
>