John, He're is our basic setup. logging to multiple places or 'sinks' - stream (file, stdout, etc), syslog controlled by runtime 'levels' so that each destination filters out what it 'stores' streams like a file should support rotation on size and/or date, with possible post rotation actions (e.g. compressing) the log processing might run under a separate thread so that the slow actions of logging can be decoupled from the main application. In real high performance situations this will probably be via some form of fixed size circular buffer per logging thread and may be allowed to drop messages on full condition (embeded style applications) other times buffer may be allowed to grow. date/time stamps switchable on/off potentially a 'source' indicator should also be logged e.g. thread id or alternatively an application provided identifier clasifications of errors/warnings/info/debug etc each with separate 'levels' should be possible. Whilst this is conceptually odd for 'error' it makes sense under debug or info. There clasifications should be user supplied to allow for domain specific messages to be routed to the correct destination multiple threads should be able to log without affecting others, I see the core of the logging system as a gather and then scatter type operation, with a M-N relations ship broken down into a M-1 and 1-N with each relationship potentially having its own buffer/queue Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |