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) RS> Well, the problem there is that it's not backwards compatible. RS> A user-implementation that is calling call_next would suddenly RS> be getting two callbacks.
<sigh> Yes - you're right of course. I'd been thinking of user-implementations as being "bottom-level" handlers, in which case it wouldn't make any difference whatsoever. But if someone has started building on the handler-chain idea to constuct their own multi-level implementations, then we can't suddently break those. OK - so we're stuck with the existing default. RS> What you've proposed is pretty much the way it works now, except RS> the default for the flag is no auto next. Except that I'm suggesting that we have a quick push to convert *all* the (internal) helpers as far as possible (and mark the exceptions clearly). I think that having a mixture of the two approaches is asking for trouble - not in terms of run-time behaviour, but in terms of ease of maintenance. It's not so bad with the v4/v5 module APIs, 'cos at least there it's obvious which approach is being used - the code looks entirely different. But I've often printed out a handler routine to puzzle over on the train - and without the creation routine, it wouldn't currently be obvious which model it was using. Dave ------------------------------------------------------- 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
