Harry,
A good debate. However, I hope that we can reach agreement on one or the
other and put it into the specification itself. The FAQ should only be
for things that come up after we've closed the specification. (I don't
want to delay closing the spec either, because no matter how long we
wait, there will always be some questions or issues like this that
come up).
I tried hard to write up the JMP and IPP specs so that your plan B was the only
interpretation. If we agree that plan A is the desired plan (or that
either A or B can be done depending on implementation), then I want
to clarify both the IPP and JMP specs.
See my comments below.
Tom
At 12:45 08/29/97 PDT, Harry Lewis wrote:
>We've had a bit of debate, here, about whether, upon detecting a cancel
>request, the agent should
>>A. STATE=Processing REASON=processing to stop point
>>B. STATE=Cancel REASON=processing to stop point
>>We were dealing with plan B when we requested processingToStoppedPoint moved
>into Reasons-1. Our current debate does not effect that change, or require any
>new adjustments to the job MIB. We are more convinced, now that
>plan A is better and I only offer this as an interoperability issue.
I agree that having two ways might create an interoperability issue.
>>The crux of the discussion is whether it's better to change State to Cancel
>ASAP upon recognizing the request (B) or
>not change State to CANCEL until the cancel operation is complete and all MIB
>values are in their final state. Earlier, we thought it necessary to reflect
>the Cancel REQUEST for timely user feedback but now we think it better to favor
>deterministic behavior from an accounting point of view. Being remote, the user
>probably won't be effected by the "lag" - and if an application really wants
>to, it can sense, from the reason, that a cancel must be in process.
on receipt of the CancelJob operation. A subsequent CancelJob operation
becomes an error if the job is already in the canceled state. But if the
job can linger in the processing state, then multiple cancels could be
done. Or the user seeing the state as still processing, might be inclined
to issue the cancelJob again (like pushing the crosswalk buttom several
times).
But lets get down to the real debate point (thanks for including your
reasons why the change): about the accounting being deterministic.
We have discussed this point at Xerox too and we feel that a robust
accounting program must be polling all the time and writing out about jobs
onto some sort of safe storage on each poll. Then if the system, or the
accounting program, or the device crash, or the acounting program doesn't
get back on its next poll cycle in time before the job is deleted,
there is still accounting information written (even if incomplete). If an
accounting program refrains from writing anything about a
job, until the job reaches one of the three terminal states (completed,
aborted, canceled), then the accounting program might miss accounting
information if any of the 4 contingencies happen. Thus we don't think
that we should change the job state model definition (of processing to
keep the job in processing until the stop point is reached) to "help"
accounting, since the accounting should be written in a more robust manner
anyway.
Thus it doesn't matter whether the accounting program knows whether
all of the data is finished changing or not (by seeing that the job has
achieved one of the 3 terminal states). The accounting program might want
to avoid re-writing a job's accounting record, if the data is all the same,
but that can be done by filtering.
In fact, each of the three terminal states, might have additional processing
after immediate transition to them.
Comments?
Thanks,
Tom
>>I'm open to comments.
>>I'd like to reach agreement and include a FAQ entry stating that, since CANCEL
>is a *completion* state, the transition should not take place until CANCEL is
>complete.
Again, I'd like to resolve before close of the document and put it in
the document, if we can.
>>Harry Lewis - IBM Printing Systems
>>