On 31 August 2011 20:27, Wes Hardaker <[email protected]> wrote:
> DS> Request for clarification:
> DS> What is the idea behind "minimalist" (?minimialist?!?),
> DS> and how does this compare with the traditional "--enable-mini-agent" ?
> The minimalist support simply removes the code that
> "needless adds to the size of the running executable and libraries".
I'm sorry, but I'm not really any the wiser.
First of all, what is meant by the "running executable"?
Is this talking about the agent, or the command-line tools,
or what?
Secondly, how do I know what is meant by "needless" code?
Needless for what? For example, will it remove SNMPv1 support?
SNMPv2c support? SNMPv3 support? All of these?
Does it affect which MIB modules are compiled into the agent?
Or is that an orthogonal decision?
> It also allows you to turn off features that are "optional", but all
> features "wanted by code somewhere else but aren't marked as a
> hard-require" are currently included.
>
> This discussion is about how to turn off all the "wants" as well so you
> really strip it down to even the bare minimals without even the
> "nice-to-haves".
I haven't really looked at the details of the feature mechanism yet.
I'm currently looking at this as a "naive outsider", and trying to
work out what I would expect this to do.
My understanding of --enable-mini-agent is that it strips out all
but the bare essentials of the agent framework, and it's then up
to the developer to put back in anything that they actually want.
By analogy, --enable-minimalist should probably work similarly
and strip out everything but the bare essentials of the overall
framework. Again it'd be up to the developer to put back in
anything that they actually want.
(either by enabling features explicitly, or by including elements
that implicitly require a given feature).
Hence this would naturally also cover the "nice-to-haves"
Given that the whole feature mechanism is new with 5.7,
I don't see any problems in changing the behaviour of these
configure flags while things bed down. This is the sort of
thing that would normally be handled as an "optional element"
for one full release cycle, before becoming part of the core release.
That's not really practical for the feature mechanism, given
how deeply integrated it is into the whole code.
But I'd suggest that features in the 5.7.x line should be regarded
as "under development", and hence be open to changes as required.
Once they have settled down (?5.8), *then* it will be time to fix
them and worry about backward compatibility.
But personally I don't think we're at that stage yet.
Dave
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders