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

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

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!