Bruce> Of the two, I find the ":" more intuitive.
Yes - that's the style that Robert and I had come to an agreement on.
(Relatively painlessly, for us!)
The 'token/subtoken' form is much older, and basically comes directly
from the mibgroup source filestructure. I don't think there's any
great attachment to this form (other than backward compatability).
Dave> But one of the major tasks is to go through the existing debug statements
Dave> and come up with a suitable hierarchical debug token structure.
Dave> (Plus identifying where we really ought to have debugging statements,
Dave> but don't!) Volunteers gratefully received :-)
Bruce> I could have a look [at this]
Bruce> What I need are the parameters for "ought".
"If I were developing an application [client/agent/MIB module]
using this part of the Net-SNMP library, and it wasn't working,
what information would I need to track down the problem".
That defines the parameters for "ought" :-)
Bruce> Does each module need a "this is what I was passed" and
Bruce> "this is what I'm handing off" blipvert?
That's one possibly aspect, certainly.
I wouldn't want to mandate this as a universal requirement, though.
Each subsystem really needs to be considered on it's own merits.
Bruce> Do we want to have scalable levels of debugging
Definitely!
That's probably the most important aspect of Robert's suggestion.
For each subsystem, we need the ability to turn on either
"light debugging" for that subsystem, or more focussed "deeper debugging"
(perhaps at a number of different levels).
For example, with the configure mechanism, I'd be looking at something
along the lines of:
-Dconfig list each (existing) config file as it's read in
and the persistent file(s) that will be used
-Dconfig:dirs list the config directory search list
-Dconfig:files list all the config files being looked for
(both existing and missing)
-Dconfig:files:parse
list each config line as it's read in
-Dconfig:store list each config line as it's saved
OK - that might not be quite the right breakdown (esp the different
debug levels of the last two entries), but it should give the basic idea.
But the first step is to identify the "interesting information" for
a given subsystem, and draw up a suitable debugging heirarchy structure
for that subsystem. I suspect that the easiest way to do this may be
to start from the "level two" debugging tokens, and then work out which
bits need either further subdivision or lowering of their priority
(e.g. "config:files:parse"), and which are "core" debugging statements
for that subsystem and hence belong at the top level ("config")
That would also serve as a first-draft of the documentation for that
subsystem's debugging tokens.
Bruce> Is this much debugging going to cause bloat? Do we perhaps need a
Bruce> compile-time debugging level token to keep the bloat down for those
Bruce> people not needing debugging?
You mean like
./configure --disable-debugging
?? :-)
Bruce> Do we want configurable multiple debugging destinations?
Bruce> eg. warnings to one file, errors to another?
Debugging is handled separately to warnings/errors.
And I don't think it makes sense to distinguish between
"warning debugging" and "error debugging" output.
I'd say that we shouldn't worry about separate destinations just yet.
That could be added fairly easily at a later stage.
The question at the moment is getting the debugging tokens organised.
That's my take, anyway.
Dave
-------------------------------------------------------
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
