>>>>> On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders) <[EMAIL PROTECTED]> >>>>> said:
DS> Robert> it stands at 2-1. DS> DS> Yes - I'm getting used to that :-( Robert> Well, we've all been there. You just need to come work for us, Robert> and then together we can rule the world! Mwuuuhaaaaahaaaaa! I've scanned the thread (I'm trying to catch up on mail again after traveling and deadline pushing). My summary, bluntly put: 1) The auto_next flag is good because it lets people reduce the stack overhead for those with weak stacks. 2) However, Robert is wrong that it helps APIs. Since we can not and should not delete the ability to have handlers do things themselves, it is unlikely it'll save us a huge amount of work if we change APIs in the future. It's much more likely that since there will be so many places that don't use it because they have to call down themselves that we'll never change the APIs but just augment them or add new ones in a backwards-compatible fashion. 3) The auto_next flag does make tracing stuff much more of a pain. I'd be tempted to make the flag dynamic in some way, and have a macro or null function called based on the current flag setting... writing code that will work optimized in some cases, but allow for better debugging in others. sigh... but it would be a mess, so never mind. <aside> I've often thought we need to introduce a whole slew of macros which would end up producing a Net-SNMP specific coding style that would transcribe into real C in order to facility short-code writing. Realistically, though, I don't think this is wise every time I think it through because as much as it helps code size, it increases the learning curve as well. Try reading the linux kernel and understanding it. I'm fairly robust at C, but I hate reading the linux kernel. And I've even read a book about it. 4) I've actually always thought that caching should be done automatically when possible instead. Like the way we have the injectable handler that wraps around any iterator (and should do other) helper implemented modules. Less code, free caching, just not *quite* as efficient at collecting data. However, it turns out that the caching itself is so fast in the tree structure that even when applied to something that already caches underneath (like the tcp table) you *still* got a speed improvement. 5) There was a 5. I forgot it. -- 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
