I have prototyped the proposed new command syntax and I would like to
hear your comments before putting the changes which will cause several
incompatibilities into the scotty-2.2.0 release. I am not explaining
all the details, so you have to read a bit "between the lines". Here
is the proposal:
1. The following commands will be unchanged:
mib load file
mib [-exact] name label
mib [-exact] oid label
mib walk varName label body
2. The following commands will be removed:
mib [-exact] module label
mib [-exact] macro label
mib [-exact] syntax label
mib [-exact] description label
mib [-exact] successor label
mib [-exact] parent label
mib [-exact] access label
mib [-exact] index label
mib format label value
mib scan label value
3. The following commands will be added to create object handles for
MIB nodes and SNMP SMI "type" definitions. The compare and info
command options have been proven to be useful and are not really
part of the proposal - I will most likely add them anyway.
mib node <label>
mib type <name>
mib compare <oid1> <oid2>
mib info <option>
4. A MIB node handle will understand the following command options:
$node name ;# returns a unique name, e.g. SNMPv2-MIB!sysUpTime
$node oid ;# returns the oid of the node
$node module ;# returns the module name which defined this node
$node macro ;# returns the macro used to define this node.
$node file ;# returns the file name which contains the definition
$node description ;# returns the description of the node
$node successor ;# returns list of handles of child nodes
$node parent ;# returns handle to parent node
$node type ;# returns the SNMP 'syntax or tc' handle of the node
$node access ;# returns the max. access value
$node index ;# returns the index handles for a table
$node scan <value> ;# converts a value into the base type representation
$node format <value> ;# formats a value from the base type representation
5. A SMI type handle will understand the following command options:
$type name ;# A unique name, e.g. SNMPv2-TC!TruthValue
$type module ;# returns the module name which defined this type
$type file ;# returns the file name which contains the definition
$type description ;# returns the description of the type
$type displayhint ;# returns the displayhint (if any) of this type
$type enumeration ;# returns the enumerations (if any) of this type
$type base ;# returns the base type or "" if SNMP primitive type
$type scan <value> ;# converts a value into the base type representation
$type format <value> ;# formats a value from the base type representation
The advantage of using handles are:
+ Handles allow to query arbitrary MIB objects, not only those that
have an OID. This makes it simple to provide fast access to "type"
information from within Tcl.
+ Accessing MIB node details or "type" information is much faster
because there is no need to search for the MIB node in the MIB tree
since a pointer to he internal data structure is saved in the Tcl
command.
+ Type "casts" are now possible by refering to the type, e.g.
set t [mib type SNMPv2-TC!DisplayString]
$t format $string
This is IMHO cleaner than the solution we are currently using:
mib format SNMPv2-MIB!sysDescr $string
Future extensions that allow to control format conversions can be
defined for the type or a MIB node separately, e.g. it might be
possible to add missing display hint definition via a Tcl command:
$t displayhint "255a"
+ The scheme can be extended to deal not only with MIB nodes or SMI
types. It should be straight forward to define a command to create
e.g. RMON2 protocol identifier handles.
There are also some disadvantages.
- Handles are not removed automatically once they are not used
anymore. This means that a loop like
mib walk x 1 { mib node $x }
will create a MIB node handle for every known node, which means
~ 5600 new Tcl commands for the MIBs that are contained in the
distribution. The overhead per command is about 45 bytes, so this
"wastes" about 246 KB of memory. This should not be a problem if
your scripts only load those MIBs that are really required.
- The changes require to update all the scripts that make use of the
commands that query MIB information and that will be removed.
I would like to hear all kind of comments. Please let me know if you
think that the advantages outweigth the disadvantages or if you think
that keeping the Tcl API stable is more important than "elegance". I
am also interested in any additional ideas for an enhanced `mib'
command. This is probably the best time to get additional features
implemented. (However, I am not working on the parser right now. So a
request to make size of range restrictions available will not be
addressed right now.)
Juergen
-- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.