On Wed, 30 Jun 2004 15:20:06 -0700 Wes wrote: WH> >>>>> On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders) WH> 2) However, Robert is wrong that it helps APIs.
Thems theres fightin' words. I would understand 'I disagree', but 'wrong' seems a bit strong. WH> Since we can not and WH> should not delete the ability to have handlers do things WH> themselves, it is unlikely it'll save us a huge amount of work if WH> we change APIs in the future. Yes, we have to maintain backwards compatibility. But that doesn't mean that we should let the API stagnate, does it? So long as compatibility is maintained, I think evolutionary changes are a good thing. WH> It's much more likely that since WH> there will be so many places that don't use it because they have to WH> call down themselves that we'll never change the APIs but just WH> augment them or add new ones in a backwards-compatible fashion. True, but most table implementations don't need to worry about it. And table implementations far outnumber helper implementations. Like I said, that means if we do enhance the API, all those implementations will immediately see the benefit, without changing their code. This is a good thing. Thinking about it more, those that need to call on their own could probably converted to use a new helper: the pre_post helper. A simple little helper with three handler pointers. That's simple than converting to a tree structure, as Dave suggested, with about the same result. The MFD helper currently uses proprietary shennanigans to have a pre/post call, but this idea feels much cleaner. WH> 3) The auto_next flag does make tracing stuff much more of a pain. WH> I'd be tempted to make the flag dynamic in some way, and have a WH> macro or null function called based on the current flag setting... <shudder> WH> <aside> I've often thought we need to introduce a whole slew of WH> macros which would end up producing a Net-SNMP specific coding WH> style that would transcribe into real C <shudder> WH> 4) I've actually always thought that caching should be done WH> automatically when possible instead. Like the way we have the WH> injectable handler that wraps around any iterator (and should do WH> other) helper implemented modules. Less code, free caching, just WH> not *quite* as efficient at collecting data. However, it turns out WH> that the caching itself is so fast in the tree structure that even WH> when applied to something that already caches underneath (like the WH> tcp table) you *still* got a speed improvement. Well that's a no brainer! It eliminates dozens of function calls as the iteration is done. Of course, it probably takes more than double the amount when you have two caches. And I'd be willing to bet it would be a much smaller speed improvement if the tcpTable was the binary array containers and the table-container helper. -- 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
