On ons, 2008-05-28 at 10:05 +0100, Dave Shield wrote:
> 2008/5/25 Magnus Fromreide <[EMAIL PROTECTED]>:
> > * How to update README.agent-mibs when using the old/new feature?
>
> My gut reaction is that README.agent-mibs should probably describe
> the implementation of the default choices. So if a module re-write is
> being trialled (using config_new_require), then this wouldn't appear
> in the agent-mibs list.
>
> If a module re-write has been included in the default build
> (with config_old_release used to switch to the previous version),
> then that'[s when it would appear in the agent-mibs list.
Tis seems reasnable for me.
> > * As it is now the list of excludes will be forever growing. Is
> > there an interest in a config_provides(interface-name)?
>
> If I've understood you correctly, the main difference between
> these two mechanisms is that config_exclude() would list
> the other module(s) that cover the same ground, while
> config_provideds() would list a shared token. Is that correct?
That is correct unless config_provides is used to add more init/shutdown
functions.
> In practise, these feel fairly similar. The main effect would seem
> to be that config_provides() doesn't require the implementor to
> know what other modules were affected (just the name of this
> token). While config_exclude() *does* require the coder to list
> the other modules explicitly.
>
> Having a common token is probably more convenient, but I'm
> inclined to say that if you're replacing another bit of code, you
> ought to know exactly what you are replacing. So listing these
> explicitly via config_excludes is good discipline.
While I agree that it is good to know what you are replacing I doubt
that it will be an issue in practice - when one is replacing code it is
always a good idea to look at the old code as well.
> > * Module initialization names - when making a new module then a
> > new module name is needed and that changes the external
> > interface of the agent. (-IusmUser vs. -IusmUser_5_5)
>
> Unless you also rename the files :-)
> (usmUser -> oldUsmUser, usmUser_5_5 -> usmUser)
That is hard to do from the config_old_require macro in the configure
script, unless you are planning some major new odd functionality ;-)
> But yes - that is a visible change.
> Whether this a problem or not, I'm not sure.
>
>
> > * I chose to add this as a config_old_require - I think that
> > config_new_require should be used to merge this into V5-4 etc.
> > save that config_new_require is missing there.
>
> I'd originally intended to add the config_{old,new}_require tokens
> to the 5.4.x branch, but the feeling of the March meeting seemed
> to indicate that it should be main trunk only. We wouldn't
> normally be introducing new features into the 5.4.x line at this
> stage anyway.
If "this stage" refers to pre?, rc? etc. then I agree, but for 5.4.3 I
think new features could be added under --with-new-features.
> New stuff should probably be trialled in 5.5, and
> made active in 5.6
So one point of this is to further delay the time for new code to get
into use? I seriouly doubt that there will be many distributors that
configure with --with-new-features.
/MF
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
