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
At 12:45 05/27/97 PDT, Peter Zehler wrote:
>Tom,
>You wrote:
>If a simple output device implements IPP and doesn't queue or spool, wouldn't
>the jobs in that output device never be in pending? Such a device would
>refuse acceptance of another job, while it was processing its current job.
>That is why pending is conditionally mandatory in IPP and therfore also in
>JMP.
>>Would it help to indicate that if an implementation queues or spools,
>that it shall implement the 'pending' state jobs that are queued or spooled
>but are not yet processing?
>>Tom
>>[PZ] I am implementing IPP in a small printer that does not spool simple
>print jobs. There can be a time when an entire print job is accepted by
>the IPP printer and the back end of the physical printer is not yet ready to
>process the job. At this point the job is blocked pending service by the
>backend print system.
>The IPP channel may accept only one job at a time. The print device may
>service multiple print channels. From the time the job is accepted by the IPP
>printer until the job is passed onto the native print system the IPP state
would
>be pending. I would not claim a job sitting in memory blocked on the
submission
>to the native print system is queued or spooled.
>Pete
>>