> On Fri, 18 Nov 2005 16:57:04 +, Dave Shield <[EMAIL PROTECTED]> said:
Dave> Taking the Boolean table as an example, this says:
Dave> The mteEventName of the event to invoke when
Dave> mteTriggerType is 'boolean' and this trigger
Dave> fires. A length of 0 indicates no event.
The counte
- Original Message -
From: "Dave Shield" <[EMAIL PROTECTED]>
To: "Wes Hardaker" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, November 18, 2005 6:57 PM
Subject: Re: DisMan Event MIB selection
On Thu, 2005-11-17 at 09:51 -0800, Wes Hardaker wrote:
Dave>
On Thu, 2005-11-17 at 09:51 -0800, Wes Hardaker wrote:
> Dave> The definitions of mteTriggerRising et al are provided as
> Dave> suitable notifications that are *available* to be sent in this
> Dave> situation - but the MIB doesn't specify that they *should* be sent.
>
> See, I didn't read them th
> On Tue, 15 Nov 2005 09:47:37 +, Dave Shield <[EMAIL PROTECTED]> said:
Wes> I think it should, as that's
Wes> the impression I got from the MIB.
Dave> Yes - I realised that from the code. But I think you're wrong.
[re: default of sending mib defined event notifications]
Err... You sh
On Mon, 2005-11-14 at 09:16 -0800, Wes Hardaker wrote:
> > On Wed, 09 Nov 2005 09:58:03 +, Dave Shield <[EMAIL PROTECTED]>
> > said:
>
> >> But does the behaviour do what the MIB says it should?
>
> Dave> In most cases - yes. (E.g. not generating a mteTrigger*
> Dave> notification u
> On Wed, 09 Nov 2005 09:58:03 +, Dave Shield <[EMAIL PROTECTED]> said:
>> But does the behaviour do what the MIB says it should?
Dave> In most cases - yes. (E.g. not generating a mteTrigger*
Dave> notification unless the mteEventNotificationTable explicitly
Dave> says to do so, whether
On Fri, 2005-11-11 at 23:04 +0100, Thomas Anders wrote:
> Dave Shield wrote:
> >What do people think about splitting this into a number
> > of separate man pages?
> I'm not convinced splitting (a lot) is too helpful.
Having to look through a multitude of itty-bitty man
pages is obviously no
Dave Shield wrote:
What do people think about splitting this into a number
of separate man pages? The basic "man snmpd.conf" would
give a general overview (and brief descriptions of each
directive), but would point to another man page for the
full details. Does that sound as if it would be
On Wed, 2005-11-09 at 09:58 +, Dave Shield wrote:
> 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 thos
On Wed, 2005-11-09 at 12:50 -0500, Robert Story wrote:
> DS> What about issuing a warning for the new code (but including it anyway)?
>
> So, something like this:
>
> - no configure option, new code, no warning.
> - configure event, new code, no warning
> - configure event-mib, n
On Wed, 09 Nov 2005 09:58:03 + 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 *litt
Dave Shield wrote:
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
On Tue, 2005-11-08 at 13:14 -0500, Robert Story wrote:
> On Tue, 08 Nov 2005 10:02:12 + 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.
On Tue, 08 Nov 2005 16:51:49 + Dave wrote:
DS> > I say we adopt something like:
DS> >
DS> > config_obsolete("Please use the new disman/event-mib module or the
DS> > older disman/old-event-mib if you still want to use
DS> > the older implementation")
DS>
DS> T
On Tue, 08 Nov 2005 10:02:12 + Dave wrote:
DS> > But you've claimed that there are no backwards-compatibility issues,
DS>
DS> Not true.
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> issu
On Tue, 2005-11-08 at 08:30 -0800, Wes Hardaker wrote:
> But Robert's complaint of not wanting to put exceptions in configure
> is a good one.
Oh, I agree.
Hardwiring the conflict check into the configure script was only
ever intended as a stop-gap measure, until someone came up with
a better appr
> On Tue, 08 Nov 2005 10:02:12 +, Dave Shield <[EMAIL PROTECTED]> said:
Dave> I'd prefer to use:
Dave> disman/event -> new code
Dave> disman/old-event-mib -> old code
Dave> (with event-mib throwing an error)
Dave> a) It avoids silently moving someone from
Dave> the old code to th
On Mon, 2005-11-07 at 13:22 -0500, Robert Story wrote:
> On Mon, 07 Nov 2005 16:52:37 + Dave wrote:
> DS> One of the concerns expressed when I first submitted my new code,
> DS> was that people who were using the original implementation
> DS> might want to continue using that version.
>
> But
On Mon, 07 Nov 2005 16:52:37 + Dave wrote:
DS> One of the concerns expressed when I first submitted my new code,
DS> was that people who were using the original implementation
DS> might want to continue using that version.
But you've claimed that there are no backwards-compatibility issues, an
Robert Story wrote:
Those who are using existing configure options shouldn't end up with the
old code.
Agreed. As long as this goal is maintained and there is a documented way
to select the old code for those who really want that, I'm fine with any
[other] approach.
+Thomas
--
Thomas Ande
On Mon, 07 Nov 2005 10:44:29 + Dave wrote:
DS> On Mon, 2005-11-07 at 11:01 +0100, Thomas Anders wrote:
DS> > Dave Shield wrote:
DS>
DS> > > So how is this selection made, and how are we planning to alert people
DS> > > to the existance of the two alternatives.
DS> >
DS> > Selection process (f
> On Mon, 07 Nov 2005 16:52:37 +, Dave Shield <[EMAIL PROTECTED]> said:
Dave> Do you mean that the difference between the two header file names
Dave> should be more distinctive, or that there should only be one header
Dave> file?
Meaning we should use the *old* name (the one people know a
On Mon, 07 Nov 2005 08:26:46 -0800 Wes wrote:
WH> > On Mon, 07 Nov 2005 10:44:29 +, Dave Shield
WH> > <[EMAIL PROTECTED]> said:
WH>
WH> >> 2) --with-cflags=-DDISMAN_EVENT_OLD_IMPLEMENTATION
WH>
WH> Dave> Yuck!!
WH> Dave> Sorry - I *MUCH* prefer the previous approach.
WH>
WH> FYI, I t
On Mon, 2005-11-07 at 08:26 -0800, Wes Hardaker wrote:
> > On Mon, 07 Nov 2005 10:44:29 +, Dave Shield <[EMAIL PROTECTED]>
> > said:
>
> >> 2) --with-cflags=-DDISMAN_EVENT_OLD_IMPLEMENTATION
>
> Dave> Yuck!!
> Dave> Sorry - I *MUCH* prefer the previous approach.
>
> FYI, I think it'
> On Mon, 07 Nov 2005 10:44:29 +, Dave Shield <[EMAIL PROTECTED]> said:
>> 2) --with-cflags=-DDISMAN_EVENT_OLD_IMPLEMENTATION
Dave> Yuck!!
Dave> Sorry - I *MUCH* prefer the previous approach.
FYI, I think it's a mistake to include 2 different almost identical
named .h files for doing the
On Mon, 2005-11-07 at 11:01 +0100, Thomas Anders wrote:
> Dave Shield wrote:
> > So how is this selection made, and how are we planning to alert people
> > to the existance of the two alternatives.
>
> Selection process (from
> http://www.net-snmp.org/support/irc/net-snmp.log.2005-11-5.html):
>
Dave Shield wrote:
How exactly should someone revert to the original implementation?
I was expecting to see some sort of new flag in "configure.in", but
there doesn't seem to be anything relevant added - just a rename of
the header file.
So how is this selection made, and how are we planning
Robert,
I notice that you've tweaked the handling of the original event
MIB vs rewritten implementations. The new approach is obviously much
cleaner than hardcoding this check into the configure script, but
there's one thing that confuses me.
How exactly should someone revert to the orig
28 matches
Mail list logo
