Re: [boost] [log] Release candidate 1

Subject: Re: [boost] [log] Release candidate 1
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-03-10 14:56:19

Le 10/03/13 16:28, Andrey Semashev a écrit :
> Hi,
>
> I've finished the docs update and released the RC1 of Boost.Log v2. The code
> can be downloaded here:
>
> http://sourceforge.net/projects/boost-log/files/boost-log-2.0-RC1-r847.zip/download
>
> The code can also be checked out from SVN:
>
> svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log
>
> The updated docs are available online:
>
> http://boost-log.sourceforge.net/libs/log/doc/html/index.html
>
> Aside from the docs updates there were a few changes I made as a part of the
> reviewing process (some were pointed out by users):
>
> - The add_attr manipulator was renamed to add_value. The new name better
> follows the terminology of the library.
> - The attribute value visitation API no longer forwards the result of the
> visitor. This feature is rarely needed but it slows down compilation
> significantly. To acquire the result one can use the new save_result function
> object wrapper.
> - Formatter and sink factories for settings parsers are now classes rather
> than simple function objects. This follows the pattern set by filter
> factories, which were classes before.
> - Fixed a few bugs and compilation problems.
>
> Sadly, there was almost no discussion of the library in this list. I received
> a few private emails on the library, mostly concerning some problems here and
> there and porting issues from v1. While valuable, this feedback can hardly
> replace a good review of the Boost community. I encourage everyone interested
> to take a look at the library, however deep you like, and provide your
> feedback.
>
> I don't plan to make any significant changes to the code, except maybe some
> include optimization and fixing the problems. If everything's fine, I'm going
> to post a request for permission to merge to trunk in a week or two.
>
>
Hi,

The review result requested to take in account some critical issues. I'm 
sure that we could found some of the answers to these question on the 
documentation, but it would be easier for the mini-review if you give 
some explicit answers to these critical issues. Telling if you have 
taken in account some of the non-critical points could help also.

Thanks,
Vicente

Critical issues
===============

These issues must be addressed, and be passed through informal mini-
review,
before the library can be added to SVN.

- It appears that the 'trivial' logging is not sufficiently good to just
   take and use. The library should provide an out-of-the-box mechanism
that:

   - supports channel/severity attributes, without creating new logger for
     each severity. It also should be possible to filter out specific
     channel by essentially poking at some "map", and without manually
     composing a new filter that checks for a set of allowed channels
     sequentally. I believe that at least Christian, Roland, Robert and 
myself
     requested this.

   - has no observable effect on compile time. One second (or more) that 
trivial.hpp
     imposes is not acceptable.

   - outputs to console by default, but permits changing that

   - outputs only component/severity/message by default, but probably 
permits
     changing that.

- By default, the library should try hard to continue working no
   matter what errors happen during processign a log record -- including
   things like invalid attribute names or types, or other exceptions.

- The library should not reinvent wheels. In particular, custom 
implementations
   of TSS and RW mutex seems like a very bad idea. Use of a custom lambda
   implementation was pointed by many as not great -- we already have a 
couple,
   so let's not add more to the mix.

- Library interface is too geared towards lambda. In particular, 
implementing
   formatters/filters as free-standing functions appears to require 
considerably
   more code. In particular, it should be possible to access an 
attribute using a
   single function call. Also, logging::extract taking a lambda for 
callback
   complicates matters, it's desirable to have a more direct variant.