[boost] Re: Logging Library over Iostreams? (was Logging Library -- Formal Review Request)

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-05-04 22:13:57

Brian Braatz <brianb <at> rmtg.com> writes:
> > On Behalf Of Darryl Green
> > struct sink
> > {
> >   void write(const log_types::stream &s);
> >   bool enabled(log_types::level l);
> > };
> > 
> > The rest of the interface (actual type) is log_manager defined.
> > A sink with the current semantics + level support implemented by
<snip>
> [Brian Braatz Writes:] 
> This thread is making me contemplate,
> Why not make this logging library a well designed bolt on to IOSTREAMS?
> I LOVE IOSTREAMS,

I won't be buying that particular t-shirt myself, but whatever...

> and it seems like if the logging library is (DESIGNED
> TO BE) an add on to that I get the best of both worlds.

Streams do formatting, streambufs do buffering (or not) and interface to the
actual I/O um - channel (to avoid overloading stream :-), including character
code conversion stuff.

You can use a stream to do the log message formatting (ie. if log_types::stream
is, as it is in the default case, an ostringstream).

You can write an appender that puts the string straight into a streambuf, there
is no formatting to do, only a (possible) code conversion.

In what way isn't this a "well designed bolt on to IOSTREAMS"? I can see is that
it is more general than is necessary if one takes the view that iostreams
provide all the facilities/customisation points you could need. I'm not of that
view.

The various customisation types used in the lib are perhaps named too closely to
their default types making it a little obscure how they can be used.

log_types::stream could be called log_types::msg_builder

log_types::string could be called log_types::msg

That is, the logging lib simply requires that there is a type that will build a
message from - well - whatever you want and that there is a way of getting the
built message from it. The message is what appenders receive.

A structured message format might be appropriate for some uses. In this case,
more/all of the formatting would be pushed to the appenders (or to the viewer).
This doesn't involve any use of iostreams except (possibly) in the appender
and/or viewer.

It would also be possible to write a streambuf specifically designed for the log
message buffering role, which generated a log_types::string that wasn't a
std:string. There might be efficiency advantages in this. It should also be
possible to have some sort of shared underlying buffer for a sequence of nested
(as a consequence of side effects) log messages so as to do the resequencing
requested by Gennadiy.