> 2009/12/16 Jordi Gutiérrez Hermoso <[email protected]>: >> Our MIB has information about what modules are available in our >> application and what information they should respond to. However, our >> modules are largely independent between each other and communicate >> with standard network protocols. Should our customers at any time wish >> more or less functionality from our product, we can add or remove >> modules, and our MIB has to change to reflect this.
A couple of further comments. It might be worth thinking in terms of having a collection of smaller MIBs - each of which defines a particular aspect of functionality. You can then supply the MIB modules that are relevant to a given customers needs. Also, remember that MIBs are effectively design documents. They say "if you get a result with this OID, then this is what it means". It's perfectly reasonable to supply your customers with the full MIB structure, even if a given agent doesn't necessarily implement all of it. That's assuming your "new OIDs" are semantically different to the existing ones - i.e. they are reporting inherently different things. If you're talking about reporting four lots of widget data on a quad-widget assembly, and just one lot of widget data on a single widget assembly, then Bart's suggestion of using tables is exactly right. Dave ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
