What if this is a strictly read-only MIB? Embedded perl would be the way to go then?
On Thu, Feb 19, 2009 at 12:47 AM, Dave Shield <[email protected]> wrote: > 2009/2/19 ntwrkd <[email protected]>: >> Why would I use one versus the other? > > Well, one significant difference is in the handling of SET requests. > > pass_persist() just has a single invocation for a SET request, > and each varbind is processed separately. That could lead to > problems if any of the assignments in the SET request could > potentially fail. > An embedded perl module uses the full multi-pass processing > (I believe), so can handle SET request reliably. > > > Another difference is that the pass_persist script will handle > each varbind separately for GET* requests as well. An embedded > perl module will be passed all of the related requests in one go. > That might allow for more efficient processing. Particularly if > retrieving the necessary data is relatively costly. > > > >> When would extending the agent via C modules be viable? > > A C-code module is more suitable for a stable MIB structure. > You said originally that > "[the OIDs]frequently change using a manual process." > > If you're modelling a MIB table, and simply meant that rows > will be added and deleted dynamically, then a C module > would be a sensible approach. > > But if it's the design of the MIB structure itself that's constantly > being changed, then a C-code module would involve frequent > re-coding and re-compilation. > (It's also not really in line with the SNMP ethos - MIBs are > expected to be stable) > > > Dave > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
