>>>>> On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders) <[EMAIL PROTECTED]> 
>>>>> said:

DS> Ok - maybe an example would help.    [...]
DS> 
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do something before and after [...]
DS> 
DS> Which is exactly what I was referring to above!

I don't think Robert ever suggested that there wouldn't be
optionality...  It was never to be forced, unless I missed something
he said (and it doesn't sound like him anyway).

DS> -  By default, handlers return success/failure, but don't explicitly
DS> call the next handler in the chain.  This is (normally)
DS> done by the main netsnmp_call_next_handler routine.
DS> (i.e. AUTO_NEXT becomes the default)

Robert> Well, the problem there is that it's not backwards
Robert> compatible. A user-implementation that is calling call_next
Robert> would suddenly be getting two callbacks.

It can not be done by default.  No way.  No how.  It would completely
trash backwards compatibility for an incredibly negligible gain.

In the future, if we wanted to define a new default flag that included
the AUTO_NEXT ability, that would be fine.  But we shouldn't change
the default behavior of existing code...

Robert> Be I think making if the default for the version 6 api would
Robert> be a good idea.

... even for version 6.

It would be far safer and far more portable to simply create a new
default wrapper flag that everyone would use by default in newer
documentation, etc, than it would be to actually break how existing
stuff works.

-- 
Wes Hardaker
Sparta


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to