On Tue, 13 Sep 2005 13:32:39 +0100 Dave wrote:
DS> Robert and I have been suggesting different forms of how to represent
DS> the requested service - either a string-based token ("snmpd:receive")
DS> or an integer ID (which happens to be the same as the default UDP
DS> port number).
I like the strings because it's easier to extend, and users can define their
own.
DS> > Deviating from that to require an app
DS> > to register something
DS>
DS> The application wouldn't *need* to register anything.
DS> *Something* would have to register the default port(s) to use for
DS> the most common service(s) on the supported transport. But I'd
DS> expect this registry to be seeded with appropriate values as part
DS> of the library initialisation.
Yep, exactly.
DS> The same mechanism would be available for the application to register
DS> appropriate defaults for any *other* service that it might wish to
DS> use (either as a client, or a server). But this should be handled
DS> automatically for the "core services".
Right. And here again, I think the strings make more sense.
DS> > then call another function with 4+ arguments
DS>
DS> As you've probably gathered, I'm not in favour of splitting the
DS> transport specification into three separate parameters.
The reason I did it that way is the multitude of ways that exist to specify
transport information. e.g. trapsinks, which have an optional port as the last
parameter. The idea is that the app shouldn't have to look at all the
parameters and build (or tear apart) input to pass to the routine. It says
"here is the (possibly NULL) transport the user specified, the (possibly null)
host and (possibly NULL) port; please deal with it for me."
If you only expect a host, the other two would be null, and the function could
deal with a possible transport/port embedded in the host string.
DS> The address string would be provided by the user, and wouldn't
DS> need to be parsed by the application-level code.
Again, if you have multiple input strings, what do you do with them? It seems
to me that passing the independently make more sense that concatenating them
to pass them into functions which are just going to rip them apart again. But
I suppose wrapper functions would make both ways work, even if one might be a
little less efficient.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
