>Tom or somebody else from the MIB project,
>could you answer some of these questions?
Pat, given some other starting point, you are probably right, SNMP
is not the ideal approach...
>I have looked at some of the stuff, and have a sinking feeling that
>the folks who are doing the MIB stuff have never tried to build/monitor
>a printing system with jobs flowing through/around it, make it portable,
>small, and able to be implemented by the lowest bidder :-)
As an aside, it appears HP has done this...
>I always try to do the simplest thing, on the grounds that the more
>complex you make it the more things you forget.
But, we're not starting at the beginning. It has taken several years
for printer vendors to respond to market demand for SNMP in their
network products - in a standard way. The complex SNMP overhead you
refer to is already there in many cases as a result. Given *this*
starting point... what seems undesirable is the need to invent and
accommodate *yet* another protocol, perhaps unless it is one that
looms so large that it can't be ignored - such as HTTP.
>Why not just define some simple MIB objects that haul text strings
>over and parse the text strings? The overhead of implementing a
>SNMP MIB with all of the complexity that they are putting in will be
>a horrific nightmare. The management of the system will be hideous,
>the database alone will be nasty to design and build, and most of the
>information will be of little use.
If we're designing a MIB that contains mostly useless information...
that's a *separate* problem!
>I also note that many of the folks on the MIB team seem to feel an
>need to have enumerated status types/messages. I keep wondering why -
>most of the time the detailed information about a state is being
>supplied in an additional message. Why not just send a text string
>with the state as the first token? It is trivial to parse this.
>And besides, for display purposes you will need to translate/index
>into a table of strings.
I agree with Don's assessment, here. You could parse fixed string definitions
and land on your feet at the same time for one of 49 languages. Where's
the benefit? If you're going to parse the string then it must be
specifically listed somewhere otherwise you are wide open to interpretation
(ex. PCL5, PCL-5, PCL5e, PCL FIVE...). A list implies a number. A
number is shorter than most strings. Why not use it?
Harry Lewis - IBM Printing Systems.