Harry has done an excellent job is describing the alternatives here,
particularly with respect to HOW one can get information using the
two different approaches.
Sheesh, I feel kinda dumb bemoaning the work we have to do in using
the Printer MIB Alert Table. The Job MIB Attribute Table makes the
Printer MIB Alert Table look like a cakewalk.
That is to say, the Job MIB Attribute Table is a walk thru hell.
Funny (not!), but as we straddle both the Job MIB and IPP efforts,
we see the IPP folks dealing with this kind of conceptual communication:
Client: "Hi, I'm Jay. Please give me the status of job XYZ"
Server: "Sure, that job's state is `pending'. Have a nice day."
(Of course, I'd rather conduct the above conversation using datagrams
instead of TCP, but that's a topic for another group... ;-)
Compare the above to the Job MIB, particularly if we eliminate the
Job State table.
Like I said, a walk thru hell.
The PMP group spent considerable time prioritizing the set of problems
the Job MIB needs to solve. It's now turning out that those priorities
don't amount to a hill of beans if the entire MIB must be overly complex
to satisfy the needs of lower-level priorities, such as accounting.
The Job State table should remain, IMHO. The replication of data in
the Job Attribute table should be removed.
In fact, if the complexity in trying to "serve two masters" gets any
worse, I'd suggest:
Define two different Job MIBs, one for status and one for accounting.
A management app designed to monitor status probably doesn't give a squat
about accounting. And an app designed to reliably capture accounting
probably doesn't care at all about status (other than the final status,
a static value, by definition).
One question that we all must come to grips with:
If a vendor wants to create a product used to monitor jobs,
will the choice of access be SNMP and the Job MIB, or IPP?
We are, after all, in the process of trying to solve the very same problem
in two completely different ways...at least when it comes to job status.
This doesn't feel good.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
From: Harry Lewis <harryl at us.ibm.com>
To: <jmp at pwg.org>
Subject: Re: JMP> JobStateValue
Date: Thu, 8 May 1997 21:23:43 -0400
You don't have to replicate jmJobState in the Attribute table since the State
table is defined to have greater persistence.
>> >Whoa, here. Replication of MIB values is an explicit non-goal of
>> >traditional MIB design, right? At least this is what Steve Waldbusser
>> >has repeatedly stated (and for good reason).
>> >
>> >If you're replicating values to somehow make it easier for a mgmt app,
>> >then I'd suggest the MIB is too complicated.
>>>> I agree completely that the same information should not have two ways to
>> be accessed. That is why I have been suggesting getting rid of
>> the Job State table altogether.
Further, Jay asked-
>This is what Harry explicitly does NOT want to do, right? (I'm asking
>just to make sure I've got these threads straight.)
Right, Jay. I do NOT want to get rid of the State Table. (I apologize,
the thread can get confusing).
>Tom, does removing the Job State Table result in the following:
> * Does not decrease the functionality needed to monitor job state,
> the number ONE reason for having the Job MIB in the first place
> * Makes the Job MIB less COMPLEX, and therefore easier to use by
> management apps and agents alike
It can be argued that moving ALL attributes (including State) to the
Attribute Table and removing the State Table will not reduce function. What it
will do is make it more difficult to monitor job progress (my opinion). Why?
Because the State Table is designed for easy index (via jmJobIndex) into a
row which contains the State and pertinent associated information. This
pertinent information changes per state. If state is pending, you don't need
to know which copy you are currently printing. If state is printing, you don't
need to know the number of intervening jobs.
If everything is lumped into the attribute table, you either have to determine
STATE and then go back for the pertinent information OR you need to grab a set
of POSSIBLE pertinent objects whenever you go for STATE and hope they all fit
in your varbind. Actually, there is a pretty good possibility that they will,
I believe. But, this is one of the problems the State table trys to address.
The only other reason I say an Attribute only solution would be functionally
equivalent but more difficult is due to the more complex indexing of the
attribute table. Attributes are indexed by JobSet, JobIndex, AttributeType,
and AttributeIndex (I may not have used the correct words here... another
dispute). The Job State Table is indexed by JobSet and JobIndex. If you are
using the "grab the state and 9 potentially meaningful values" method described
above, we think the response will be quite a bit slower due to the agent
handling all this indexing.
Slower response and complex indexing may be OK for the accounting application
(where we've always seen the greatest use for the attribute table), but
the job progress monitor may want quicker. Really, it may not even be a matter
of who can tolerate slow response as much as a matter of how many clients
or servers could be polling for job progress vs. the (fewer) number of
accounting apps putting the agent through it's paces on the attribute table.
>what can you tell us about Xerox's experience in prototyping this version
>of the standard Job Monitoring MIB?
Yes, I would like to hear anyone's response to the above in terms of their
prototype experience. I have been trying to share our findings rather openly.
Harry Lewis - IBM Printing Systems.
----- End Included Message -----