[SNMP4J] Improved table index
Frank Fock
fock at agentpp.com
Tue Jan 31 20:32:38 CET 2006
Hello Matthias,
Matthias Wiesmann wrote:
>Hello everybody, Frank,
>
>I have done some modifications to the MOTableIndex, basically I added
>a new variant of createIndex that takes an array of variables and
>creates a table index out of it.
>The method is not static and uses the impliedLength parameter to build
>up the index in the correct way. It also does some basic checking that
>the variables match the types of the subindexes.
>
>
>
Good idea. I will add such a method too.
>The goal of these changes is that if you declare the table indexes
>public and static, the definition can be use both on the agent and the
>client side, this way, if the table definition changes, the code does
>not need to be changed. I also have changed the field declaration so
>that both the array of subindexes and the impliedLength field are
>final, this way, instances are invariant and can be safely shared. The
>same changes were be done to the class MOTableSubIndex.
>
>
>
I will (or have already) change the AgenPro templates to make the index
definition
public and final.
>One thing that strikes me in the code of this class is that there are
>a lot of switches on the syntax of variables. It might make sense to
>move the index building functionality directly into the different
>subclasses of Variable, maybe with methods like:
>
>void fromIndex(OID index) ;
>OID toIndex(boolean implied_length);
>
>
>
These methods will also be added to v1.7. It is a natural property of
many SMI values
to be able to be converted to/from an index.
>On a related note, could it be possible to have the table index and
>OID declaration public in the snmp tables of the MIB declaration of
>snmp4j-agent? This would make writing client code simpler if the
>client code could reference the relevant objects instead of defining
>again the same constants.
>
>
MOTable.getIndexDef() is already public and as I wrote above, the
AgenPro templates are already changed accordingly.
Many thanks for your valuable contribution!
Best regards,
Frank
More information about the SNMP4J
mailing list