[boost] Logging library review

From: Vadim (vadimz_at_[hidden])
Date: 2008-02-18 03:37:33

 > * What is your evaluation of the design?

Good analysis of the target domain, clean separation of concerns. 
However the flexibility of this is throwing too much burden on the user 
and has made the barrier to entry too high. IMO, simple usages can be 
made simpler without sacrificing much of extendability.

 > * What is your evaluation of the implementation?

Didn't look much into it

 > * What is your evaluation of the documentation?

Too complex and can turn away many potential users. Too many times terms 
   are introduced without being clearly explained. It lacks a natural 
flow and appears chunky. Maybe the choice of doxygen to partly to blame 
since it encourages such style. Maybe it is great for "advanced" 
section, but introduction could benefit from old-fashioned sequential 
writing.

 > * What is your evaluation of the potential usefulness of the library?

Significant. Every project I encountered needed a logging facility, and 
this library is open enough to actually cover significant portion of 
uses with some extending.

 > * Did you try to use the library? With what compiler? Did you have any
 > problems?

In a simple test project with VC 7.1, trying to re-create functionality 
provided by v1 of the logging library, namely the ability to create a 
hierarchy of loggers, such as "system.network.tcpip" or 
"system.storage.db", and configure different outputs dynamically, based 
on modules and levels, at run time.

* Single threaded configuration not supported, fails with somewhat 
cryptic message in cache_before_init:43

* a list of dependencies on other boost libs in the docs could be helpful

* could not figure out which tradeoffs that scenario::usage is supposed 
to resolve.

* decoupling the tags example from scenario::usage turned out not trivial.

* hit some sort of appender vs prepender conflict while playing with 
combining named_spacer with tags formatter.

* didn't like the DEFINE_LOG_XXX /DECLARE_LOG_XXX macros and would 
prefer to have the code behind them visible.

 > * How much effort did you put into your evaluation? A glance? A quick 
reading?
 > In-depth study?

About 6 hours overall. Within that time frame, I have been unable to 
replicate v1 functionality, but it appears that the design does not 
precludes it. However, I'd strongly prefer that functionality to be 
available out of the box.

 > * Are you knowledgeable about the problem domain?

Reasonably so: I've evaluated several logging libraries, developed and 
deployed my own library in past. Also had experience integrating 
boost::logging v1 library into ~100KLOC project.

 > And finally, every review should answer this question:
 >
 > * Do you think the library should be accepted as a Boost library?
 >     Be sure to say this explicitly so that your other comments
 >     don't obscure your overall opinion.

Yes, with some improvements to documentation and ease-of-use, I believe 
it will make a valuable addition to boost.

While I agree with previous reviewers about quality requirements for 
boost logging library, my opinion is that "yes, with improvements" vote 
will better serve that purpose, in encouraging John not to go for 
another 2-year redesign cycle.

Best regards,
Vadim