Re: [boost] Logging library - Organization of effort

From: Andras Erdei (ccg_at_[hidden])
Date: 2002-04-11 02:37:04

On Wed, 10 Apr 2002 09:59:38 -0400, "Ernie Makris" <ernie_makris_at_[hidden]> wrote:

>The question now is, how to proceed.
>I think that people that said: "I have logging library X" should place the 
>code of the said library on the boost server. I've created a directory named 
>\logging-library.

What's the deadline ? (I'm in the middle of writing one...)

If anyone want to comment (so i can incorporate ideas during
the developemnt) my current design consists of three layers.

1. The bottom layer contains the sinks (a base-class for 
user-defined sinks, and pre-implemented memory, file, tcp/ip 
and a platform-dependent interactive display).

The first three sinks have no locking mechanism
(i assume that each thread will use a separate
logfile etc), but the last one exists in both
thread-safe and thread-unsafe forms.

2. The middle layer is essentially:

#define LOG diagnostic() << hack( __FILE__ , __LINE__ )

diagnostic() returns a (thread-specific) string stream;
hack()s dtor automagically appends the source file name,
line # and timestamp information, then sends the content
of the stream to the sinks active for the curent thread.
It can be used as:

        LOG << "this is logged " ;

Additionally, there is an object whose ctor/dtor calls
the indent()/undent() members of the sinks, passing in
__func__, __FILE__, __LINE__ -- my sink implementations
indent with spaces for file logging, and create/close 
sub-branches in a tree-view for interactive logging.
I don't know how customizable this should be (someone
mentioned using < and > instead of indentation).

The sink-management will also be part of this layer; to
prevent coupling with the thread library threads can only
manage their own sinks -- what i don't know is how to
remove sinks... Maybe there'll be only a function for
detaching all the sinks.

3. The topmost layer is a bunch of macros for level-based
logging.

Message filtering occurs at the topmost layer (levels
can be turned on/off at compile time), and in the sinks.
(There is no filtering for file, tcp/ip & memory sinks,
and the interactive sink will have a pattern-based filtering
mechanism; the filters are set runtime, by the user.)

Any comments/suggestions ?

TIA
andras