I've posted a paper on issue 43 and other clarifications
needed for the jmResourceTable which I'd like to go over
at the JMP meeting this Friday, 2/6.
-rw-r--r-- 1 pwg pwg 57344 Feb 2 00:17 res-type.doc
-rw-r--r-- 1 pwg pwg 55631 Feb 2 00:18 res-type.pdf
-rw-r--r-- 1 pwg pwg 57108 Feb 2 00:19 res-type.pdr
I'll bring copies of the res-type to the JMP meeting
this Friday in San Jose.
Here is the beginning of that paper:
Subj: Problems and Solutions to the jmResourceTable - Issue 43
From: Tom Hastings
Date: 2/1/97
File: res-type.doc
There are several problems with jmResourceTable:
1. The jmResourceName object cannot be a union of a text string and an
integer.
Proposed solution to Issue 43: Have two objects: one for text and the
other for an enum type for those resources that have identified enum types,
such as interpreters.
Call these objects: jmResourceNameAsText and jmResourceNameAsType.
2. It is not clear for objects that do not have a need for a text name or
text type, whether the jmResourceNameAsText need be filled in at all.
Proposed solution: Always fill in jmResourceNameAsText with some text
string. For most resources jmResourceNameAsText shall be a fixed string
specified by the MIB, such as 'pages completed' or 'sides'. For the
remaining resources, the MIB would require filling a variable name, such as
the actual file name, the actual document name, or the interpreter name.
For those resources that have jmResourceNameAsType, such as channel or
interpreter, both the jmResourceNameAsText and jmResourceNameAsType would be
filled in.
I would think that for internationalization/localization that it would help
if all resources have a fixed text string, if the name isn't a variable text
string. Then if a new enum is supported by an agent that the monitoring
application didn't understand, at least the text string name could be
displayed to the user. Of course, such a text string would be in the locale
of the server or printer, which we expect to be the same as the monitoring
application.
New ISSUE 54: Do we need a way for the monitoring application to determine
the locale of the server or printer? Then the monitoring application would
know whether to use the jmResourceNameAsText directly or to use the
jmResourceType enum that all resources have (not to be confused with the new
jmResourceNameAsType object) and provide the localization for the user
within the monitoring application.
3. It is not clear for those resources that are not counted, such as
interpreters, what the value of the jmResourceAmount should be. I suggest
that we specify that it shall be 1.
4. I've added mediumRequested and mediaConsumed.
5. I've added outputBin and colorantConsumed.