Note number 19 questioned whether we really needed Pause-Current-Job.
The advantage of Pause-Current-Job was that the client didn't have to supply
the job-id (but could as a check against the race). On the other hand, the
Pause-Printer doesn't need a job-id. And then the operator could check to
see what was the current job and the use Pause-Job where he MUST supply the
job-id. So I agree that we really don't need Pause-Current-Job.
Note 21-24 dealt with the other Xxxx-Current-Job operations:
In fact, following the same line of reasoning and pruning out operations, do
we really need the other two Xxxx-Current-Job operations: Space-Current-Job
and Cancel-Current-Job? Perhaps the Xxxx-Current-Job operations were more
needed for command line interfaces than for more recent GUI interfaces which
would likely be displaying the job queue with job-ids for all jobs or at
least the current job id.
1. Space-Current-Job when we have Space-Printer which works when there is
and isn't a current job.
We could add an OPTIONAL "job-id" to Space-Printer which would reject the
request if the current job didn't match. This would help the race condition
that the current job might just finish or a new job start just as the
Space-Printer operation was issued.
2. Cancel-Current-Job when we have Cancel-Job as a REQUIRED operation.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, July 13, 1999 12:55
To: ipp
Subject: IPP> OPS - Notes and Agreements on IPP Admin Ops from IPP WG
meeting, 7/7/99 in Copenhagen
snip...
19. Do we really need Pause-Current-Job. Most people felt that Pause-
Job was sufficient.
snip...
21. ISSUE: Does we really need a Space-Current-Job. This seems very
specific to roll-fed printers.
22. ISSUE: Is Space-Current-Job reasonable to do in the 'processing'
state when paper is still moving?
23. ISSUE: In the 'processing-stopped' state, is there a "current"
job?
24. Should be Space-Job with job-id if in spec at all.
snip...