JMP Mail Archive: Re: JMP> Job States and State Reasons

Re: JMP> Job States and State Reasons

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 17 Mar 1997 18:14:05 PST

The reason for two separate objects, is that the job states can't be
added to without breaking application software. If PWG registers
more states, such software will get some new state that it doesn't understand.
The idea is that the application software is likely to do something
based on a state, but is NOT likely to do anything based on a job-state-reason.
Only the human is interested in the job-state-reasons.

The job-state-reasons are extensible, since they aren't really new states,
but are additional information or sub-states. If an application gets a
job-state-reason that it doesn't understand, it not a big problem.

For an embedded controller without much memory, why not leave out most
of the job-state-reasons? Perhaps only the completion with errors or
success?

WE could make jmJobState a type 1 enum, instead of a type 2 enum,
to reflect this strategy?

This is the same strategy that we are taking in IPP as well where the
job and printer states are type 1 enums.

Tom

At 16:18 03/17/97 PST, Harry Lewis wrote:
>Classification:
>Prologue:
>Epilogue: Harry Lewis - IBM Printing Systems
>
>I've stated before, but perhaps not strongly enough, that I think job state and
>job state reasons should be combined into one OID in the job MIB. It must be
>that DPA defined it as two, I guess that's what is driving the spec today. But,
>try and implement this in an embedded controller. There you are wasting 4 bytes
>times every entry in your State table. If you are designing for persistent data
>(across polling cycles, not with NVRAM) in the printer, you want as many
>entries as possible in the table.
>
>Is anyone else designing for embedded controller who shares my opinion strongly
>enough to make a comment? Anyone who feels the job MIB, in general, is too
>cumbersome for embedded controllers?
>
>Harry Lewis - IBM Printing Systems
>
>