Hi Darryl, Sorry for the late reply...
I think you (or anyone) should be able to implement levels by changing the manager only, although I guess that depends on what "implement levels" really means.
I also think appenders/modifers should be able to be removed as well as added. It seems to me that the manager should deal with appender add/remove (or connect/disconnect if you prefer) in a way similar to enable/disable (or levels).
Yup, you are correct.
However, to be able to do that appenders (or connections to them) need to be comparable. It should be possible to write a manager to do this (eg one that indexes appenders by name), but the logger interface won't let me.
Given the various requests/discussion surrounding exactly how some parts of logging should best be done, I still think the simplified manager-log_impl interface I proposed previously, where the manager provides an appender/modifier vector to the log_impl, has both performance advantages and allows more flexibility in manager implementation/features. However, it probably isn't general or clean enough an interface, and this could be addressed by providing a concept something like the following, to replace the (not customisable at present) logger_impl.
I really like the sink concept. I could do something like: get_sink("app.*").set_level(LEVEL_DEBUG); get_sink("app.*").add_appender(some_appender); get_sink("app.*").del_appender(some_appender); The easiest way to implement deletion of appenders/modifiers, is to allow naming them. Once an appender has a name, when you say: get_sink("app.*").del_appender( "my_cool_appender"); it will remove it. This will remove all appenders with that name. I think this would be quite an easy to use solution. What do you think? 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!