Re: [boost] Proposed Logging Library review

From: John Torjo (john.groups_at_[hidden])
Date: 2008-02-11 16:09:09

Hi Amit,

Thanks for the review.
>> * 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.
>
>   
Got that - will make it much simpler in the next version.
>> * What is your evaluation of the implementation?
>>     
> Unwieldy & too reliant on preprocessor macros. Namespaces are over-used. Some
>   
The idea about namespace = concept was a very easy way to look for 
possible implementations of a concept once you know it.
Perhaps I did abuse it, though.
> important considerations have been overlooked (e.g. output encoding, state of
> the log destination, automatically logging exception conditions).
>   

About state of log destination : basically I'll ask people to vote for 
the features they'd like. Because I've got quite a few conflicting ones :)
About logging exception conditions : what do you mean?
> 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).
>   
Thanks, keep me posted ;)
>   
>> * What is your evaluation of the documentation?
>>     
> Comprehensive, but too informal. Ultimately insufficient to aid in understanding
>   
About informal - got it, will formalize it.
>   
>> * 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.
>
>   
Yup, will do.
>> * 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.
>
>   
About logger & filter in one - will be there.

About code conversion - will talk privately.
>
>   
>> 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.
>
>   
About irrelevant object - you're right, won't be there in the next version.
> I look forward to the outcome of the review, and offer my services for testing
> any revised implementations.
>
>   
I'm pretty sure of the outcome of the review :) But I'll ask for another 
review to take place in about 3.5 months.

As for testing - I'll take you up on that offer ;)

Best,
John

-- 
http://John.Torjo.com -- C++ expert
http://blog.torjo.com
... call me only if you want things done right