On Wed, 30 Jun 2004 15:52:23 +0100 Dave wrote: DS> Having a set of handlers called "in sequence" is a perfectly reasonable DS> alternative model. I'm unconvinced as to whether it's necessarily DS> better than the current "pipeline" model, but it's certainly not a DS> poor choice.
I'm not sure I see the difference. The way I see it, all that is changed is who calls the next handler - the currently handler, or the agent library. DS> I think the pipeline has some advantages - it's somewhat more flexible DS> in terms of exactly when and where the next handler is called, DS> and what (if anything) is done afterwards. I don't the what I'm proposing takes away any flexibility. The two methods will co-exist in peaceful harmony. :-) DS> What I'm really objecting to is having a hybrid of the two. Ok, maybe it won't be so peaceful. I think both are necessary. The 99% case will be lower handlers that know nothing about handlers below them, and don't care. The next handler will be called for them. Some of the helper handlers, however, do care. Again, bulk_to_next is the best example. It needs to do something before and after lower handlers are called. I supposed we could word around that with a tree-like structure, to allow a next_sibling in addition to the current next_child. DS> If we're going to work this way, then I think we need to first DS> agree on this (and exactly what model to use), and then make a DS> concerted effort to make the change across the board. Well, we need to come to consensus real quick then. 5.2 is rapidly approaching. DS> In particular, is a simple list of handlers likely to prove sufficiently DS> flexible? Might it be worth having a tree structure of handlers, for DS> example, which would allow for "post-lower-level-handler" processing at DS> any given point? DS> (That's perhaps not very clear - I'll have to think about how DS> better to describe this concept) No, I understand perfectly. I'm just not convinced that it's not simpler to have handlers that need such processing just deal with calling next handler internally. eg otherwise the bulk handler would need to be split in two. DS> Robert> it stands at 2-1. DS> DS> Yes - I'm getting used to that :-( Well, we've all been there. You just need to come work for us, and then together we can rule the world! Mwuuuhaaaaahaaaaa! DS> Now I've just got to work out what this means w.r.t. the descriptions DS> for the book. I'm more and more thinking that I should have followed DS> my initial impulse, and pulled out of the project completely until DS> that was finished..... Hmm.. pulled out of what project until what was finished? At any rate, it's just like my inetNetToMedia problem. It's never easy to track a moving target. -- Robert Story; NET-SNMP Junkie <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. ------------------------------------------------------- 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
