Boost.Log library formal review.
Please explicitly state in your review whether the library should be accepted.
Yes, library should be accepted. Some explanation here. What means 'boost library' to me? It's very reliable, portable, efficient, sexy (in sense of code style) component that could satisfy from 90 to 95 % of regular user cases. Even if someone has an issue with such component - this issue could be resolved quickly (up to 1 hour). This quickness usually explained by clean library design and also by rich community support (the last sentence I've made based on my own experience with boost). IMHO, Boost.Log nicely fits into all the written above. Andrey spent many months (I've put an eye on Boost.Log in August 2008) polishing library's design, implementation, improving documentation. It would be nice to see the result of such huge efforts in Boost distribution. - What is your evaluation of the design? The overall design seems to be very orthogonal and does not mix different things together. - What is your evaluation of the implementation? I didn't dig deeply (except some functionality related to log rotation). At first glance, it's high quality, modern c++ code. It doesn't take too much time to understand it and make modifications. - What is your evaluation of the documentation? The first thing I except from any documentation - it's a "quick jumps" scenarios, i.e. workable small code snippets that compiles, works and give the user brief explanation on how to perform usual tasks using the library. I've found it in the latest docs and that was nice. Tutorial section is organized in 'from simple to complex things' form. This is very nice. Overall quality of the documentation is fine to me. - What is your evaluation of the potential usefulness of the library? Every application could really benefit from using logging. Especially server ones, that are running 24/7 without frequent human interaction. But I'm saying banal things now. In short, potential usefulness of such library is very high. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I've tried it. gcc 4.1.2 (RHEL 5 x86_64, RHEL 5 i686). msvc 9 (Windows i686). The only problem I had it was warnings on gcc. But that was RC3 of the library, I guess Andrey addressed those issues in the latest version. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? We've integrated Boost.Log RC3 into our server application (in the end of January 2008). Now it's running in several production environments. I've spent several days writing tiny wrapper for Boost.Log. This wrapper was required due to reasons above: 1) I was not sure about the future: whether we would like to switch to the different logging library etc., nowadays answer to this question is categorical NO 2) All the components of application should have common logging formatting, logging levels, also some 'shortcuts' were needed (such as namespace aliases etc) Also, we did some Boost.Log profiling with valgrind (memcheck tool). As far as I remember, none issues were found. - Are you knowledgeable about the problem domain? Knowledgeable from the end-user point of view. I know, what I want to have from logging (e.g., various severities, filtering, log files rotation, thread-safety). - Questions I have one question in regards to log rotation. (I guess, I was asking it last year when RC3 was presented). Is it possible to setup log rotation in a following way: file.log - earlies log file (today) file1.log - older log file (yesterday) file2.log - oldest log file (the day before yesterday). This way Apache, Samba etc. performs rotation. Also, this rotation behavior is default in Python logging module. Also, this behavior is default in my wolrd ;). Many thanks to Andrey for Boost.Log contribution. Many thanks to Volodya for being a review manager. Regards