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

Subject: Re: [boost] [log] Boost.Log formal review
From: Darryl Green (darryl.green_at_[hidden])
Date: 2010-03-17 10:30:00

I didn't think I'd have enough time to give this lib the attention it
deserves, but as it turns out I've become sufficiently frustrated trying
to use it that it has made reviewing easier...

The library provides a good set of sinks out of the box, and it is
relatively easy to add more.

The interface used to actually log through is ok but it would be nice to
make it easier to tailor to specific requirements.

Given that filters have to expect that they will receive records from
any/all components of an application that use boost log they need to:

1) very efficient

2) not fail (especially not throw) when expected attributes are not
present or (where this is possible) attributes are not of the expected
type/format. The latter aspect I comment on more below.

I don't believe that the library achieves either of these.

In addition the decision to avoid the coupling that would be required if
exact attribute types were shared between the producer of the record and
the filters seems reasonable - but it uglifies and complicates attribute
access. In practice I don't believe it is required (there is no logging
example or library provided attribute where knowledge of the type is
not, in practice required/shared). It is however, clearly necessary that
the actual set of attributes not be required and that attributes / types
not known to the filters should be able to be ignored by the filters. I
don't think these constraints should be too hard to meet while
addressing 1 and 2 above and improving attribute access.

If attribute access was simpler I wouldn't really care about the filter
"lambda" or the formatting facilities as there would be no reason to use
any logging specific facilities for these purposes. This would be an
improvement as it avoids introducing yet another domain specific idiom
into user code.

Given the library scope there needs to be far more documentation, but I
would rather see a smaller library that uses other libraries and
established idioms (by which I do not mean printf :) instead of
(re)inventing them. This comment is primarily directed at the filtering
and formatting facilities, and the main barrier to removal of the
existing facilities is the attribute access "quirks".

I would really like to see mechanism where an enabling filter can be
applied to loggers based on one or more constant valued attributes such
that if the filter does not match the cost of invoking the non-matching
loggers is very low.

I've read the docs and some of the implementation.

I've complied the lib and run a examples using gcc 4.3

As others have noted compilation speed is not a great feature of this
library.

It is a utility library and several users have said that they find it to
be useful. However it isn't usable for me for some important use cases
(the efficiency of "disabled" logs issue). I'm also concerned that this
exact issue, as well as some of the filtering and formatting issues,
would become even more significant and apply to many uses of the library
if logging via this library was to become pervasive/the norm in widely
used libraries (ie if in an application using a number of libraries the
logging for all of them was handled via boost log). For these reasons I
vote against the inclusion of the library in boost. I thought about
making this a conditional yes based on addressing some of the above -
but as this would mean removing some and radically changing other parts
of the interface of the library this doesn't seem like a workable
approach.

Darryl