Robert> I'd say there should be a configure option to choose the new/old
Robert> style implementation.
Dave> configure --with-mib-modules=ucd-snmp/extensible
Robert> I assume that this would enable the old-style?
Yup
Robert> And the new style has a new name? Or is in a new directory?
Both - it's the module 'agent/extend'
> there are two conflicting mandates. Fix bugs, and maintain backwards
> compatibility. The only way to do both is parallel support/tokens.
> However, we do deprecate things once in a while (command line options)
I'd emphasis that it's *only* the (invalid) relocatable form that's
affected here. I've already got a backwards compatible implementation
of the other traditional form (which also fixed a couple of bugs in
the 'ucd-snmp/extensible' implementation). So anyone who's currently
using "exec token command" could continue unaffected anyway.
It's only "exec OID token command" usage that would be hit. In some ways,
it's unfortunate that we've been using the same config token for both.
> My proposal:
>
> 1) new token for new mib ('extend'?)
> 2) document new token in man page. Mark old option as deprecated
> 3) optionally log warning at startup for old token
> 4) in a future release, drop old token support
I was thinking in terms of an alternative approach (based around
possibly-temporary "new-exec" and "old-exec" tokens), to allow a
gradual change-over of config files.
But the more I think about it, I suspect your plan above is a reasonable
one. The only significant variation I'd sugges might be to issue warnings
(and eventually drop) the relocatable form of "exec", rather than the
whole token completely.
On balance, I'd still prefer to change the behaviour immediately,
but I can well understand the reasons to proceed more cautiously.
Would you be happy with deprecating this in 5.2 and dropping it in 5.3?
> Having proposed that, if there is a majority support for just changing the
> behavior and updating the FAQ, I wouldn't raise a stink.
Majority support? Hah!
There seems to be a general lack of interest in any aspect of the
development of this package at the moment :-(
I'm going through another phase of wondering how long we'll be able
to continue to keep it going and supported properly.....
Dave
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
