Logging Class Part #1 : That's the way I log it

In my previous post I mentioned, that a good logging class is a must for any-scale project. Now it's time to take a look at what Mono may offer us on this subject.
At this very moment, Mono has implementation of System.Diagnostics Trace, Debug, Switch, standard Switch-type and Listener classes. As far as I studied Microsoft (heh - I'm using payed MSDN library to learn free Mono classes) help for tracing features of .NET, this set of tools (with using custom switches, of course) will provide me full access to the logging power of C#.
Using of this tools is really easy to understand. You have a great variety of choices for making your logging class really flexible to be used in all parts of your (and mine too) project.

Let's take a little structure overview of the future logging class.

As we create an instance of the class, we should let it know where to store messages that we pass to it. You may store them to some system-specific logging system, to a database or a simple text file. As showed performance-test of all this ways of storing data, the best performance provided when using simple text file for output. But depending on the specifics of your project, you may use database for better after-analysis and system-specific logging system to provide end users with necessary information.
At this moment Mono does not support Framework 2.0 TraceSource class of System.Diagnostics, but this feature may be easily implemented within your own class.
For my project, I'm planning to use simple text files for storing error, warning and in-game event messages. About in-game events - I think, maybe an extra log-parser will be written to find any information I need.
That's all for now. In the next article, I'll tell how to set different log levels for program-specific needs.