[Mono-list] Diagnostic Messages

Jonathan Pryor jonpryor@vt.edu
27 May 2002 09:11:45 -0400


Comments inline.

On Mon, 2002-05-27 at 03:24, Dwivedi , Ajay Kumar wrote:
    Hi all,
    	Great discussion going on. I couln't resist jumping in ;)
    I like the trace functionality but don't like the way they are used. I mean
    writing my own tracelistener etc..Here's my suggestion for the trace classes
    based on the discussion.
    
    We should Use the config file as in the .NET , our aim is to make mono run
    exactly similiar or better than .NET :) For each key defined in the
    settings,
    we add a class to the Trace.Listeners by reflection. And every call to
    Trace.Write() calls the Write() methods on eash of the objects in Listener.
    
I intend to implement application configuration file functionality.  I'm
not sure *when* I'll get there, but I plan on it.

    The default should be not to do anything. The DefaultTraceListener can send
    the output to /dev/null but that would be an added overhead.
    
Actually, just ignoring the output is easier, and minimizes overhead.

    As lupus suggested, we should allow Environment Variable based
    configurations too. This is especially needed when the application and its
    configuration settings are readonly for a user. (There doesn't seem to be
    any security risks involved)
    
A reason I hadn't considered.  However, I would hope that application
configuration files would be per-user on Unix, so that there wouldn't be
read-only configuration files.

    Further, mono should have some built-in TraceListeners. These should include
    syslog, file and console listener. Lazy developers like me might not like to
    write their own listeners ;) We can use the syslog library call for
    implementing syslog.
    	   
File and console listeners are already present: see the
`TextWriterTraceListener', which can take a `TextWriter' (such as
`Console.Out') or a string filename as arguments.

`syslog' looks like it wouldn't be a good idea for diagnostic messages,
since the root user would need to get involved in order to view the
messages.  Instead the `System.Diagnostic.EventLog' (and related)
classes would probably be a more appropriate wrapper for `syslog'.

    Happy Hacking,
    Ajay
    
    PS: While going through the Mono source for Trace class, I see all the
    methods delegated to an internal class. Trace is not an abstract class, so
    is there any particular reason for doing so?
    
Primarily because the `Trace' and `Debug' classes are 99% identical. 
The only difference between the two classes is that the `Trace' methods
are conditional on the `TRACE' symbol, while the `Debug' methods are
conditional on the `DEBUG' symbol.  Hence the presence of `TraceImpl',
to contain the shared functionality.

 - Jon