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

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-22 20:33:44

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

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

Pretty much, yes.  I am on the fence about a singleton, but it seems
to be the logical conclusion of allowing different logging
topics/channels and solves the logger declare/define "problem".

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

They are orthogonal.  In an application I might have topics like
"network", "memory", "queues", "statistics", etc.  Levels would
typically be debug, info, warning, error, fatal, etc.

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

Assuming they could be strings, why would they need to be pre-declared?

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

I'd think they would be even simpler to configure if the interface was
more dynamic (e.g. string based).  The names of topics used in the
configuration should be enough to configure the entire logging
hierarchy.

> What would the advantage of having channels be?

You can control/gate the output (e.g. adjust severity levels, perhaps
even select output destinations) based on them.

The more I think about it, channels really are similar or identical to
your logger concept, but I'm much more comfortable/famliliar with a
singleton-based logger that uses channel "names" that are strings. 
This removes the requirement for pre-declaring and defining loggers
explicitly in code which I dislike.  Adding new topics is just a
matter of changing your code to log using a new topic name.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com