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