Re: [boost] Re: Proposal: Logging library

From: David A. Greene (greened_at_[hidden])
Date: 2002-04-09 21:13:29

Javier Estrada wrote:
> After reading all the email, I'd like to summarize the aspects that need to
> be balanced in such a proposal:
> 
> - Instancing
>    a) Static (ala cin, cout, cerr, clog) ?
>    a) Singleton ?
>    b) "Multiton"?

I'm not sure what you mean here.  Are you talking about specifying
sinks?

> - Destination
>    a) Single target
>    b) Multiple Targets - What's better? Composition? using a design pattern,
> like Decorator?

Definitely multi-target, IMHO.  Maybe I want to print all messages
to the console (so I can read all of them) but keep a buffer of
the last N messages so if the program crashes I can see what happened
leading up to the crash.

> - Optional output information
>   thread id, process name

Function name, file name, any number of other things.  I think much
of this should be explicitly coded by the programmer (i.e. the actual
logging function shouldn't add much message text).  Formatting should
be layered on top of logging.

> - Severity (Levels)

As has been stated a few times (but perhaps not strongly enough), levels
alone doesn't cut it.  IMHO, any good logging library should allow
controlling of output by specifying module or "mesage type" names (i.e.
give me the debug output [level 3 and below, or maybe just levels 1
and 4] for the L1 cache of my processor simulator).

> - Add your own

Others have mentioned controlling the logger from an external interface.
I think that's a great idea if it is workable in a generic fashion.
Perhaps this is something that could be layered on top of the logging
library as a separate component.

> IMHO, a logging library for boost should follow the streams philosophy and
> be based on streams.

It should also allow other usage if/when appropriate.  Could this be
made a policy somehow?

                                  -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson