On Wed, 09 Nov 2005 09:58:03 +0000 Dave wrote:
DS> > Are there good reasons for the incompatibilities?
DS>
DS> Apart from trying to annoy you and Wes, you mean? :-)
Yes, apart from that.
DS> What do you think, Robert? Yes - there are good reasons
DS> for the incompatibilities. Give me a *little* credit, please!
DS>
DS> > Especially something like -i vs -I, which seems like it would be trivial
DS> > to fix.
DS>
DS> I was deliberately trying to improve the consistency between configuring
DS> events and configuring monitors - in particular for specifying which
DS> varbinds to add to a notification.
Any particular reason that couldn't be done with new options, instead of
changing the meaning of the old option? And leaving the original meaning for
the original option?
DS> Wes' original implementation had two different meanings for '-i'
DS> With "notificationEvent", it added an individual instance (rather)
DS> than wildcarded) varbind to the notification payload
DS> With "monitor", it specified that the *whole* monitor entry referred
DS> to a specific instance (rather than a wildcarded object), and
DS> there was no way to add an exact instance varbind to the payload.
DS>
DS> I tweaked things so that '-i' referred to the notification payload
DS> varbind in both cases, and introduced a new '-I' flag for the instance
DS> based monitor.
DS> The config parser *tries* to handle the old "monitor -i" semantics,
DS> but it's not infallible.
Ok, does it work for the most common, simple cases we expect most people are
using.
DS> > DS> > I don't particularly like this option, but will bend to the will
DS> > DS> > of the people. I would argue that the header name for the old code
DS> > DS> > should indicated it is the old code.
DS> > DS>
DS> > DS> Like 'disman/old-event-mib' does, you mean?
DS> >
DS> > I'm fine with that for the old stuff. I don't really like the idea of a
DS> > new third option for the new code, and breaking existing packages/build
DS> > scripts.
DS>
DS> What about issuing a warning for the new code (but including it anyway)?
So, somethng like this:
- no configure option, new code, no warning.
- configure event, new code, no warning
- configure event-mib, new code, warning
- configure old-event-mib, old code, no warning
DS> I could live with issuing a warning about the change, but continuing
DS> the configuration to use the new implementation anyway. That wouldn't
DS> require touching anything, but would still alert people that things
DS> had changed. Or alerting those who bother to read the messages, anyway.
DS>
DS> That's probably the best compromise I can come up with.
DS> How does that sound to you?
I agree it's probably the best compromise we'll agree on.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
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
