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!