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

From: John Torjo (john.lists_at_[hidden])
Date: 2005-05-21 23:44:10

Hi Darryl,

Thanks for the thorough feedback, once again ;)

> 
> 
>>3) Different formats (modifiiers) for different observers.
> 
> 
> Yes. This one is annoying because it turns the modifiers/appenders list into a
> tree. I think this is where it becomes better to resort to a structured log
> message format, where modifiers are only used to add additional structured data
> such as timestamps to log messages, and where formatting this data is left up
> to the appender. So long as it is easy to compose an appender from a "dumb"

Not sure why shouldn't the modifier do the modifying :) (that is, the 
formatting), and the appender do the writing -- seems quite logical to me.

> 
> a) No singletons. That is, I want to be able to have logging using multiple
> managers with different policies in a single app. While this may sound a little
> weird, I need something that looks an awful lot like logging to actually log
> application level events, in specific formats etc independent of application
> debug/error logging. This is a failing of the logging lib I had been using.

I'm also in favor of no singletons myself.

> 
> b) Dynamic/scoped logs are essential. I know they are in the design already,
> but it is one feature that doesn't seem to get many requests and, despite (e)
> below, one feature I can't do without.

ok.

> 
> c) There are different interpretations of the named logs/keywords/tags/channels
> being kicked around. I'd just like to register a definite vote for the named
> log approach as currently implemented. It achieves everything I've ever wanted
> from this sort of attribute, very efficiently. If some other post filtering
> naming is needed (it isn't by me), it can just be another attribute in a
> structured log message.

Thanks ;)

> 
> d) Thread safety is required (as is the ability to turn it off). Minimise lock
> scope and hold time. Appenders must implement their own thread safety anyway
> (unless a global lock is used, which would be bad) given that they can be
> shared by multiple logs. Except during updates to settings the logs themselves
> should be reenterant.

Yes.

> 
> e) If feature lists lead to code size/data size/performance compromises thats
> fine, so long as I can turn off features I don't want. Layering or policies
> please. Embedded systems may have a lot more memory and MIPS than they once

I'm certainly stiving for this.

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!