Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Doesn't seem like it would take too much of a filter to the existing
application to convert the enum values back into pairs, if that's what's needed
at that end.
Reducing the number of job states called out or changing them to type-2 enums
is not the issue. My concern is number of OIDs.
--- Forwarded by Harry Lewis/Boulder/IBM on 03/17/97 09:33 PM --
jmp-owner at pwg.org
03/17/97 07:17 PM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jmp at pwg.org@internet
Subject: Re: JMP> Job States and State Reasons
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
Harry Lewis - IBM Printing Systems