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

Reply via email to