[Mono-list] Diagnostic Messages: Proposals

[Jonathan Pryor]

Background:

Ah, the joys of reading documentation...

The Remarks section of:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfaddelementforlistenerselement.asp

specifies that the `Debug' and `Trace' classes share the same Listeners
collection.  My own tests confirm this, and the current Mono
implementation of these classes also has them share the listeners,
primarily because they're both just wrappers to `TraceImpl'.

What this means is that it would be difficult to modify the
`DefaultTraceListener' so that if it was called from `Debug' it would do
one thing, and do something else if called from `Trace'.  (Not
impossible, just not trivial.  Arguably such behavior would be
undesirable, as it would introduce incompatibilities with .NET. 
However, some of the proposals also introduce incompatibilities, so
there are trade-offs everywhere.)

That, for me, kills my suggestion for a ``--diagnostic'' argument for
mint/mono.

However, I still don't like how the `DefaultTraceListener' currently
works.  It always sends output to the console, which may be
undesirable.  (There's also the fact that the console output it
generates is ugly, but that's a different matter.)

Apparently several of you agree: by default you don't want to see the
output of the `DefaultTraceListner' class.  I'm inclined to agree.

Which raises a question for me: how should we specify how
`DefaultTraceListener' should behave?

Note that application configuration files do not enter the picture here,
as the config file would only allow you to add or remove the
`DefaultTraceListener', and not change its behavior in any major way. 
If this is incorrect, please let me know, but this is my current
understanding of the .config file schema.

The proposals:

Proposal 1: Never send output to the console.

The `DefaultTraceListener' has a `LogFileName' property that can be set
if a log file should be generated, so console output isn't strictly
necessary.

My issue with this solution is that setting `LogFileName' can't be done
from a configuration file (that I could determine), and would thus
require explicit programmer support.

Thus, this proposal is the equivalent to saying: "Ignore the
`DefaultTraceListener'.  If you want to see diagnostic messages, create
an application configuration file and add another listener."

I don't like this solution, as (1) application configuration files
aren't currently supported on Mono, and (2) I can't make the application
configuration files work on .NET.  (It keeps complaining that it can't
find the `System.Diagnostics.TextWriterTraceListener' class, which is
annoying me, especially since I'm copying the SDK examples.)


Proposal 2: Always send output to the console.

This is the current situation (assuming that you compiled your C# code
with the DEBUG or TRACE symbols set).

I don't believe it to be sufficiently flexible, and could lead people to
remove diagnostic messages from their code if diagnostic messages will
always be present.


Proposal 3: Use a MONO_TRACE environment variable.

This is based on what Paolo Molaro suggested.

By default, no messages are sent to the console.

If output is desired from the `DefaultTraceListener', set the MONO_TRACE
environment variable.  Three value categories would be recognized:

	Console.Out: send output to standard output
	Console.Error: send output to standard error
	<anything else>: Treat <anything else> as a file, and assign
		this value to the `LogFileName' property.
		This would have the effect of writing diagnostic 
		messages to the specified file.

Both `Console.Out' and `Console.Error' would take a "prefix" that is
prefixed before all diagnostic messages, allowing them to be separated
from normal program output.  For example:

	MONO_TRACE="Console.Out:** "

The prefix would be everything after the first ':'.

The downside with this proposal is that it introduces an incompatibility
with .NET, as .NET won't support the MONO_TRACE variable.  I don't
consider this to be significant, as .NET supports `OutputDebugString',
which I find to be a preferable solution anyway.

I prefer Proposal 3, but I'm willing to implement any of these proposals
(or others, if suggested).

Thanks,
 - Jon