On Wed, 14 Sep 2005 09:52:53 +0100 Dave wrote:
DS> On Tue, 2005-09-13 at 12:22 -0400, Robert Story wrote:
DS> > The reason I did it that way is the multitude of ways that exist
DS> > to specify transport information. e.g. trapsinks, which have an
DS> > optional port as the last parameter.
DS>
DS> Which is an approach that we've been trying to move away from.
DS> If a user wants to specify a non-standard port, then that should
DS> be part of the transport address string.
I agree, but we also are supposed to maintain backwards compatibility. Or
maybe that doesn't apply to configuration tokens?
DS> > The idea is that the app shouldn't have to look at all the
DS> > parameters and build (or tear apart) input to pass to the routine.
DS> > It says "here is the (possibly NULL) transport the user specified,
DS> > the (possibly null) host and (possibly NULL) port; please deal with
DS> > it for me."
DS>
DS> But the user will typically specify the transport information as
DS> a single string - that's the model we've been working towards
DS> for some time now. So your approach would need to tear this string
DS> apart in order to get at these elements separately.
No, then intent is that only the available input (thus all the 'possibly
NULL' above) would be passed. Thus, if the input is a single string:
netsnmp_xxx(NULL, host, NULL);
and the library would deal with it. In the trapsink case, it would be:
netsnmp_xxx(NULL, host, port);
and the library would deal with the fact that the host may also have an
embedded port.
The transport parameter is most likely to be NULL, and I only added it on the
vague notion that at one point there was (is?) probably a command line option
to specify using TCP instead of udp. I can't think of any other situation
where the transport is specified separately (as far as parsing goes) from the
host.
DS> It feels to me that we're probably working with different expectations
DS> of how the transport information will be provided. My position is that
DS> multiple input strings will be the exception, you seem to be thinking
DS> that this will be relatively common.
Not so much that it would be common, but rather the efficiency argument of
putting them together then pulling them apart.
DS> > But I suppose wrapper functions would make
DS> > both ways work, even if one might be a little less efficient.
DS>
DS> Actually, that's the general sort of direction my mind was wandering
DS> too. How about a library utility routine that would take separate
DS> transport, host and port specifications, and combine them into a
DS> single transport string? (bearing in mind that the host string might
DS> already specify either a different transport or port already)
That last bit is exactly why I don't like combining them. I think the library
has a better chance of trying to interpret two distinct conflicting strings
than one conflicting string. Especially since the separator character we've
chosen coincides with the one for ipv6 addresses. So I'd suggest the wrapper
be the single parameter function, which calls the 3 param version with 2 null
parameters.
And since I'm not planning on writing the code here either, I've said my
piece, do with it what you will.
--
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:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
