On Tue, 2005-11-08 at 13:14 -0500, Robert Story wrote: > On Tue, 08 Nov 2005 10:02:12 +0000 Dave wrote: > DS> If you look at the message where I first reported my new implementation, > DS> that explicitly states that there *are* some backwards-compatibility > DS> issues. Mostly fairly minor (e.g. -i vs -I), but they are there. > > Hmm... I just re-read the thread, and I didn't see any such caveats. I also > noticed that your original intent was to replace the original implementation.
My apologies. I thought I'd mentioned these explicitly - seems I was wrong. Sorry. > Are there good reasons for the incompatibilities? Apart from trying to annoy you and Wes, you mean? :-) What do you think, Robert? Yes - there are good reasons for the incompatibilities. Give me a *little* credit, please! > Especially something like -i vs -I, which seems like it would be trivial to > fix. I was deliberately trying to improve the consistency between configuring events and configuring monitors - in particular for specifying which varbinds to add to a notification. Wes' original implementation had two different meanings for '-i' With "notificationEvent", it added an individual instance (rather) than wildcarded) varbind to the notification payload With "monitor", it specified that the *whole* monitor entry referred to a specific instance (rather than a wildcarded object), and there was no way to add an exact instance varbind to the payload. I tweaked things so that '-i' referred to the notification payload varbind in both cases, and introduced a new '-I' flag for the instance based monitor. The config parser *tries* to handle the old "monitor -i" semantics, but it's not infallible. > DS> And the behaviour is subtly different as well (e.g. what notifications > DS> are sent when an explicit event is specified). > > But does the behaviour do what the MIB says it should? In most cases - yes. (E.g. not generating a mteTrigger* notification unless the mteEventNotificationTable explicitly says to do so, whether to generate traps on startup). In one particular case - no. (The Event MIB spec is broken wrt the order in which varbinds are added to the notification payload list. My implementation supports both the "correct" order, and the order that actually works properly, defaulting to the working behaviour) But that's requires a fairly specific configuration to trigger the difference, so I don't expect it to cause too many problems. > DS> > I don't particularly like this option, but will bend to the will of the > DS> > people. I would argue that the header name for the old code should > DS> > indicated it is the old code. > DS> > DS> Like 'disman/old-event-mib' does, you mean? > > I'm fine with that for the old stuff. I don't really like the idea of a new > third option for the new code, and breaking existing packages/build scripts. What about issuing a warning for the new code (but including it anyway)? > DS> > You're not going to easily get > DS> > people to use the new code if it isn't turned on easily > DS> > in the fashion they're used to. > DS> > DS> But the new code is being included by default. They don't > DS> *need* to turn it on - it'll be provided automatically. > > But the people using the old implementation will be forced to change something > to even be able to configure. Ah, diddums! :-) It's not exactly a difficult change. Actually, I see that as an advantage, because it means that they will *definitely* know that something has changed, and will be forced to think about which version they want to use. Remember that we're talking about early adopters here - typically the somewhat more experimentally minded people. I could live with issuing a warning about the change, but continuing the configuration to use the new implementation anyway. That wouldn't require touching anything, but would still alert people that things had changed. Or alerting those who bother to read the messages, anyway. That's probably the best compromise I can come up with. How does that sound to you? 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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
