On Tue, 2005-09-13 at 12:22 -0400, Robert Story wrote:
> 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.
Which is an approach that we've been trying to move away from.
If a user wants to specify a non-standard port, then that should
be part of the transport address string.
It's just as easy to configure the agent using
trapsink localhost:1162
as it is using
trapsink localhost community 1162
(In fact, it's *easier*, since the integrated address string
doesn't need to specify a particular community, and can pick
up whatever 'trapcommunity' is set to. But I digress....)
> 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."
But the user will typically specify the transport information as
a single string - that's the model we've been working towards
for some time now. So your approach would need to tear this string
apart in order to get at these elements separately.
> 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 feels to me that we're probably working with different expectations
of how the transport information will be provided. My position is that
multiple input strings will be the exception, you seem to be thinking
that this will be relatively common.
> 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.
Actually, that's the general sort of direction my mind was wandering
too. How about a library utility routine that would take separate
transport, host and port specifications, and combine them into a
single transport string? (bearing in mind that the host string might
already specify either a different transport or port already)
That would provide the flexibility for implementing an application
that handled such things separately, while retaining the simpler
APIs of the single-string approach.
Dave
-------------------------------------------------------
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
