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

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-19 14:49:29

On 5/19/05, John Torjo <john.lists_at_[hidden]> wrote:

> In order to make the Logging lib as usable as it can be, I'd like to
> know what is *your* scenario, when using a Logging lib.

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.
 Default will send output to stdout if nothing is explicitly specified
by the user.

* 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.

* 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.

* 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?

* Thread-safe.  Two threads should never have their messages
intermixed as they would with raw ostream<< operations.

* 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.

* 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)

* 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.

If a data structure is used to represent the message instead of just a
std::string, this information can be captured.  Some folks might not
like the overhead associated with timestamping etc., so perhaps this
could be provided through an alternate interface, e.g.:

   BOOST_LOG_RECORD (topic, level, message << goes << here)

would create a structured log_record object fully populated with
thread ID, timestamp, topic, level, etc but

   BOOST_LOG (topic, level, ...)

would create a log_record with only the message, __FILE__ and __LINE__
data initialized (the latter two should cost almost nothing).

* 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.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com