DS>If you look at Richard's list, you should be able to see the two heirarchical forms - one using tokens of the form: DS> helper:baby_steps DS> helper:cache_handler DS> helper:debug etc
DS>and one using: DS> host/hr_device DS> host/hr_disk DS> host/hr_filesys etc Of the two, I find the ":" more intuitive. I'd even think about "helper.babysteps". DS>But one of the major tasks is to go through the existing debug statements and come up with a suitable hierarchical debug token structure. DS>(Plus identifying where we really ought to have debugging statements, but don't!) Volunteers gratefully received :-) I'm just about to write a swack of code that will have my fingers in half-a-dozen pies. I could have a look while I'm at it. What I need are the parameters for "ought". Does each module need a "this is what I was passed" and "this is what I'm handing off" blipvert? Do we want to have scalable levels of debugging - from a "watch everything" mode down to "watch my tiny piece" independent of the hierarchies? Is this much debugging going to cause bloat? Do we perhaps need a compile-time debugging level token to keep the bloat down for those people not needing debugging? Do we want configurable multiple debugging destinations? eg. warnings to one file, errors to another? This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users