On Fri, 2005-09-09 at 16:16 -0400, Robert Story wrote:
> On Fri, 09 Sep 2005 09:39:20 +0100 Dave wrote:
> DS> The place for knowledge about per-transport defaults is in the
> DS> transport-specific domain handler, where the person coding this
> DS> *would* know what the default values should be for particular
> DS> services.
>
> True, but they wouldn't know what the user wanted the default to be.
Hence the idea of a netsnmp_{set,get}servtoken() API.
(I'm not particularly convinced by the name, but that's
not important right now).
> DS> - either as a string representation ("udp:localhost:161", etc),
> DS> where not all the elements need necessarily be present,
> DS> and possibly accompanied by an (optional) default port.
>
> How about actually using a service, as you suggested earlier, and the user
> provided strings? Since some existing code gets the information in 3 pieces, I
> suggest the api have 3 parameters, plus the local/remote flag:
>
> netsnmp_xxx("snmpd:receive", user_transport, user_peer, user_port, 0);
> netsnmp_xxx("snmpd:agentx", user_transport, user_peer, user_port, 0);
> netsnmp_xxx("snmpd:trap", user_transport, user_peer, user_port, 1);
This is starting to feel extremely confusing, from the application
developer's point of view. I'd prefer to see something a little less
complicated.
Ideally, setting up a connection should be as simple as:
netsnmp_xxx("where_spec");
If we want to support the idea of (per-service) default ports, then
this needs to be extended to indicate the service involved somehow.
Hence:
netsnmp_xxx( "where_spec", SERVICE_ID );
But I'm reluctant to complicate this any further.
Instead I'm drawn by the idea of separate client- and server-side
API calls (rather than a separate local/remote flag).
So that would imply something like:
netsnmp_open( "where_spec", SERVICE_ID ); // remote
vs
netsnmp_listen( "where_spec", SERVICE_ID ); // local
That's functionally the same as your 'netsnmp_xxx' call,
but with parameters 2-4 merged into a single string.
(and with a numeric serviceID rather than a string)
> During init, defaults would be registered:
>
> netsnmp_yyy("snmpd:receive", "udp", "localhost", "161");
> netsnmp_yyy("snmpd:agentx", "unix", "/var/agentx", NULL);
> netsnmp_yyy("snmpd:trap", "udp", NULL, 0);
Hmmm...
I wasn't taken with this idea initially, but the more I think about
it (and the accompanying config directive), the more I like it.
I still suspect that a numberic serviceID might be more natural
for an application programmer, but the basic idea is a good one.
Dave
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
