Hi Caleb, Thanks for the input!
Not sure if this qualifies as a "scenario", but these are my high-level requirements for a logging framework:
* Easy to select/change output destinations (e.g. stdout/stderr, file, syslog, etc). Output can be sent to multiple destinations if desired.
you know this is already there ;)
Default will send output to stdout if nothing is explicitly specified by the user.
This is a nice touch. Should be doable, rather easy...
* Configurable output format. User should be able to associate a format with an output destination (where applicable - it may not make sense in all cases). The current modifier chain does this reasonably well.
Thanks ;) As said, in the future, I'd like to create another lib which would allow easy configuring of the logging lib. Of course, volunteers are always welcome ;)
* Channels or topics or keywords. I think various people have asked for this by one or more of these names, and I like the idea as well. This can be implemented with separate loggers in the current implementation, but I'm not sure how I feel about that. It doesn't feel right to me.
So, a channel would be the eqivalent of the existing logger, and we'd have a singleton logger?
* Severity Levels. Topics have a configurable threshold at or above which they will output a message; messages of a lower severity are ignored. Users specify the severity level with each message. This is orthogonal to the channel/topic/keyword, but should be configurable by c/t/k or with wildcards (e.g. logger.threshold ("*", logger::levels::warning); logger.threshold ("net", logger::levels::debug)). What about user-defined levels?
User-defined levels - will definitely be possible.
* Thread-safe. Two threads should never have their messages intermixed as they would with raw ostream<< operations.
Yup
* Logfile rotation. For file-based logs, there should be a way to configure the framework to . The appenders you included in 1.3.3 implement this.
Yup, thanks!
* Simple interface using ostream::operator<<. If my classes have streaming support, they should be log-able. Something like:
BOOST_LOG (logger, topic, level) << message << goes << here
or
BOOST_LOG (logger, topic, level, message << goes << here)
How do topic and level differ?
* Structured log records. In order to implement thread-safety, there must understandably be some level of buffering. I like the current ts_appender with its timed batching of writes, but you lose some information like the name of the logger to which the message was originally sent. I think it is imperative that a logging "call" is able to capture a precise timestamp, thread ID, topic, severity, and __FILE__/__LINE__ info at time the message is created.
Note: this should be doable with a custom log manager.
* Setup. I'm not enamored of the requirement of declaring & defining loggers (or using scoped loggers). If the channel & severity concepts become first class citizens, is there any reason not to have a singleton logger? Or perhaps a singleton logger could be made available, and users could provide their own loggers instead if they desired.
Well, I don't know. If we were to have channels, you'd still need to declare them somewhere (so I'd know which channels are there). And then, defining them was needed to be able to externally access a log (so that you can allow configuring the logs by "scripting" - by possibly reading a file, which contains how logs are configured). What would the advantage of having channels be? -- 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!