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
> * 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
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
* 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk