Re: [boost] Re: Logging library - your own scenario!

From: John Torjo (john.lists_at_[hidden])
Date: 2005-05-22 00:10:35

> 
> controlled by runtime 'levels' so that each destination filters out
> what it 'stores'

Will do.

> 
> streams like a file should support rotation on size and/or date, with
> possible post rotation actions (e.g. compressing)

Latest version allows rotating logs.
> 
> 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.

There's a ts_appender() with similar functionality.

> 
> date/time stamps switchable on/off

You can do this by adding or not adding a prefix_time() modifier.

> potentially a 'source' indicator should also be logged e.g. thread id
> or alternatively an application provided identifier

Again this is possible by adding a custom modifier.

> 
> 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

To do.

> 
> 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

Yup, the lib is thread-safe.

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter)
-- http://www.torjo.com/cb/ - Click, Build, Run!