Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-18 14:08:03

On 03/18/2010 01:57 PM, M-Square wrote:
>
> INTERFACE COMPLEXITY
> =====================
>
> When implementing the various sinks and backend flavours I too found my code
> blurred with heavy template and shared-pointer handling at a level where I
> didn't want to see it. Thinking about how to improve this, it seemed to me
> that the library was lacking an extra interface level between trivial
> logging and the low-level interface of sinks etc. This extra interface
> should hide complexity, but still allow the user full control over the
> detailed aspects of the logging components.
>
> In my view this extra-level interface could be well-solved with a
> policy-based design. The user should just be required to provide the
> policies for the various aspects (front-end, back-end, formatter, filters)
> as well as the necessary parameters (file name etc.). The actual assembly of
> the logging components should be done by the library internally.
>
> I put this idea into practice, and, although not an expert in this field,
> developed a few policy-based creator classes, as well as the most common
> policies that I could forsee. This made the library much easier to manage
> and my code look much better.
>
> Adopting this approach would greatly remove the objections against the
> highly complicated interface. Users can just use the policies provided, and
> if the ones provided do not fit a user's needs, he can easily copy an
> existing one and modify it according to his wishes. The current design of
> the library allows insertion of this extra interface level well, proving its
> flexibility.

Thanks, this looks like an interesting idea. This made me thinking about 
changing the sinks design in order to make it less verbose to initialize 
on one hand and more extensible on the other. The idea is to present the 
sink as a pipeline of consumers, which would include the current 
frontend, backend and probably other things. Something like this comes 
to mind:

   typedef sink_pipeline<
     synchronous,
     formatter,
     text_file
   > sink_t;

   shared_ptr< sink_t > s = new sink_t(
     file_name = "file_%N.log",
     rotation_size = 1024 * 1024,
     ...
   );

I think, it would also make it possible to connect several backends with 
a single frontend and/or a common formatter, which was requested during 
the review.

> DESIGN/IMPLEMENTATION ASPECTS
> ===============================
>
> When using the library I came across a few design aspects that might need
> some improvement.
>
> 1. Missing some polymorphism
>
> I know it is cursing in the church, but at certain moments I could do with a
> bit smarter use of polymorphism. To give an example, when my application
> shuts down unexpectedly, I want to tell the sinks around to stop their work
> and dump their contents if necessary. For the moment, and as far as i know,
> I still have to make a distinction between synchronous and asynchronous
> sinks, as only the asynchronous sinks support these stop methods, and even
> then I have to take the particular kind of backend in consideration in order
> to approach them, as this stop method is attached to the backend-templated
> class. It would be better to lift these methods to a class higher in the
> hierarchy.

Hmm, a reasonable suggestion. I think, a flushing method could be added 
to the basic sink interface. However, I'm not sure about the stopping 
method, since it only makes sense for asynchronous sinks.

> 2. In some cases, you might want to be more in control of what the logging
> library is actually doing. When sending off messages to a sync or async
> sink, you are only partially in control. Therefor my idea would be to
> provide something like a buffering logger, that buffers the messages it
> receives, and only sends it off to the core when the user tells him to.

I think, this should be doable by implementing a logger feature.

> HIGH-PERFORMANCE REQUIREMENTS
> ================================
>
> I haven't performed comparison tests in detail, but from the results
> published it looks like Boost.Log is still lagging a bit behind in the
> multi-threaded case.

AFAICT, the results show the opposite. According to the tests, Boost.Log 
scales slightly better than log4cxx.