[boost] Proposed Logging Library review

From: Amit (contact.lipik_at_[hidden])
Date: 2008-02-11 12:00:45

> * What is your evaluation of the design?
I think the library is overdesigned, learning curve is too shallow & very
difficult to comprehend for a casual user. Author has persevered with the notion
of employing namespaces to encapsulate concepts - this leads to a profusion of
unrelated names & types, apart from the arguable soundness of this approach.

I reckon that the problem is that the author has designed the library to make
complex tasks easy - e.g. if you wanted to use multiple filters controlling
logging to mutiple destinations, this is probably the only library that would
help you. But the cost of that power is that typical usage has become too
complicated.

> * What is your evaluation of the implementation?
Unwieldy & too reliant on preprocessor macros. Namespaces are over-used. Some
important considerations have been overlooked (e.g. output encoding, state of
the log destination, automatically logging exception conditions).
But I am using code from the library just for the ability to log on a dedicated
thread (with some changes). This alone is worth persevering with the library.
I am satisfied that the code itself is stable and largely error-free - it has
been running on a live web-server for a week now, without any issues
(fingers-crossed).

> * What is your evaluation of the documentation?
Comprehensive, but too informal. Ultimately insufficient to aid in understanding
the implementation/usage details of the library. But my point is that the
implementation is so scattered that any amount of documentation might be
insufficient.

> * What is your evaluation of the potential usefulness of the library?
I think that with a simplified design, discarding of maybe 25 out of the 30+
namespaces used, automatic defaults for typical tasks, no reliance on macros,
this would be a very useful library for almost all C++ developers.

> * Did you try to use the library? With what compiler? Did you have any
> problems?
I did & do use it. ICL 10.1 on XP. I have interacted with the author to get some
issues solved. I had to change the stream class to accept a flag that flushes on
every write, when logging on a dedicated thread. Also, logging to file, cout etc
are not possible with this library if the required code conversion is not
supported by the locale. I attempted to create an object encapsulating the
logger and the filter (since the library does not intend to provide one) but
could not since the return type of the overloaded destination::<< is implicit -
author did try to help but his suggestion did not work.

> * How much effort did you put into your evaluation? A glance? A quick
> reading?
> In-depth study?
All of the above, + 1 week integrating the library into my application.

> * Are you knowledgeable about the problem domain?
I am now :-)

> 
> 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.
Not in its current form. Withsupport for output encoding, provision for objects
so user can just include the library and start dumping messages with having to
create irrelevant objects (like optimized string - optimized for what? how?),
the lib would have my unqualified support.

I look forward to the outcome of the review, and offer my services for testing
any revised implementations.

Best
Amit