Robert> Replace 'eliminating the redundant loop' with 'eliminating an Robert> unnecessary function call and reducing the stack depth.' (Have you Robert> looked at a back trace from a low level handler? It's horrendous.)
No argument there! <wry grin> Robert> I think that it's that it's a change from how you understood things Robert> worked, not that it's a bad idea. I'd bet if it had worked this way Robert> from the beginning, you wouldn't have thought twice about it. Probably not, no. Having a set of handlers called "in sequence" is a perfectly reasonable alternative model. I'm unconvinced as to whether it's necessarily better than the current "pipeline" model, but it's certainly not a poor choice. I think the pipeline has some advantages - it's somewhat more flexible in terms of exactly when and where the next handler is called, and what (if anything) is done afterwards. But your concerns over the effects on the function stack are perfectly reasonable - that was probably my main reservation when Wes first suggested this model. What I'm really objecting to is having a hybrid of the two. If we're going to work this way, then I think we need to first agree on this (and exactly what model to use), and then make a concerted effort to make the change across the board. In particular, is a simple list of handlers likely to prove sufficiently flexible? Might it be worth having a tree structure of handlers, for example, which would allow for "post-lower-level-handler" processing at any given point? (That's perhaps not very clear - I'll have to think about how better to describe this concept) In retrospect, I should have probably raised this issue when you first adjusted the sparse_table handling (which I now see follows the same idea). Robert> If I thought I could have gotten away with it, Robert> I would have made the flag "DONT_AUTO_NEXT", so the flag would only Robert> need to be set in the unusual case Yes - that makes sense. If we're going to switch away from the pipeline model, then this would definitely be preferable. DS> But this feels somewhat less confusing than the AUTO_NEXT behaviour, DS> which I really don't think is necessary. But I'm probably in a DS> minority of one yet again. Robert> Well, I don't know if any of the other core developers are going to Robert> speak up. When I checked in the code, Wes said "good idea", so Robert> unless he has been swayed by your argument for clarity, it stands Robert> at 2-1. Yes - I'm getting used to that :-( Robert> However, unless there are objections to the whole concept, most of Robert> the other handlers are in the queue for the chopping block to be Robert> updated to use auto-next (bulk to next being on the top of the list). I'd actually be somewhat happier if we *do* intend to change everything over. As I said above, it's this hybrid of the two approaches that is really confusing. Now I've just got to work out what this means w.r.t. the descriptions for the book. I'm more and more thinking that I should have followed my initial impulse, and pulled out of the project completely until that was finished..... 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
