[boost] Logging Library Review

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-02-17 23:40:27

Logging library review

This is my first boost review, so could be it lacks a lot of things..

* What is your evaluation of the design?
IIUC, the library provides a flexible solution to compile-time
definitions of different loggers.
IMO, this is rarerly the case. What should be configured at compile
time are the tags (or simplier, the message type).
All the rest, destinations, formats, interval, caching, etc is not the
responsibility of the programmer defining the log, this is the
responsibility of some other programmer using the first programmers
library, or the customer using the first programmers application.
Destinations will be added at runtime (such when opening a telnet
console, typing 'enable-log debug' or similar), configured at runtime,
removed at runtime.
These scenarious are not even discussed, which make me doubt the library.

It seems that formatters are attached to the top level writer object,
is this the only way?
The formatted message may need to vary for different destinations.
I would typically have the file logs to include more data (tags, if you will)
then the console destination, making it easier to read the console for
human eyes(no timestamps, codelines, etc).
If there are some data missing while I look at the console, I would at
runtime change the formatter to include some more.

* What is your evaluation of the implementation?
Didn't look much, but I'm strongly against configuration macros and
small utility macros for things that could be written without them.

* What is your evaluation of the documentation?
I share the same opinion about the documentation as others have
already said. It's confusing to read, and sometimes I think that the
library is more useful than the documentation makes it, but I'm not
convinced.

* What is your evaluation of the potential usefulness of the library?
A logging library is indeed very useful, I am not sure about this one
though. I don't agree with other reviewers that boost must have a
logging
library for its own sake. With spirit, for instance, I can enable
logging to std::cout perfectly for debugging my grammar, no need for
very large frameworks for that. Talking about which, how would that
work with the proposed library?

* Did you try to use the library? With what compiler? Did you have any
problems?
Tried some of the samples with vc8, no problems.

* How much effort did you put into your evaluation? A glance? A quick reading?
In-depth study?
Read the documentation a couple of hours and looked at the examples.

* Are you knowledgeable about the problem domain?
Yes. I've written and maintained a log library that's been running for
many years.

* Do you think the library should be accepted as a Boost library?
No, sorry. Could be that the flexibility and customization I am
looking for is in there already, but the documentation is written with
other scenarios in mind than I have.

It should be addressed how the logging library will be configured when used in:
* an external header only library (ex, spirit).
* an external compiled static library (ex, serialization.lib).
* an external compiled dynamic library (ex, serialization.dll/so).
* an application, that is shipped/sold to third party.
* an application, where destinations are added/removed at runtime from
multiple threads.

To me a logging library plays a very important role in large software
projects since it becomes a part of the interface of an application,
note merely being a building block for the programmers behind the
application (like std::vector<> for instance =).
What is goal of the library?

Regards,
Christian