Re: [boost] Review of Logging library begins today February 4th

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-02-05 19:57:38

[This is a continuation of my previous premature post - is there a pill for 
that?]

>> - where is the default mode that just works "out of the box"
>>
>>
> How about this:
> http://torjo.com/log2/doc/html/scenarios_code.html#scenarios_code_mom
>

If I could write something like;

#include <boost/logging.hpp>

using ...

void test_mul_levels_one_logger() {
    log() << "hello world";
}

and this resulted in a file with the content;

    2007-2-7_at_13:33:22 "hello world"

The file would have the same name as the application and would
appear in either a configured folder, a default folder or the working
folder.

That would be closer to "out of the box" for me. Again there wasnt
anything in your library precluding this. I would just have to create
the supporting code.

>> * What is your evaluation of the potential usefulness of the library?
>>
>> Useful. This looks after most of the needs relating to developers
>> debug output and also more permanent support output. It does not
>> appear to consider what often occurs with such output - it may be
>> the best or only record of system activity and will become the
>> focus of more complex post-processing and analysis. The library
>> does not specifically cater to such activity.
>>
>>
> Not sure what you mean. Why do you think I neglected that?

See below.

>> * 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.
>>
>> No. As an example of a developers debug logging facillity this is
>> one of the better ones. A Boost logging facillity should be targeted
>> slightly
>> differently. Solving the requirements of developers debugging should be a
>> side benefit of solving the wider issue of recording system activity
>> for any of the system stakeholders.
>>
>>
> Again, not sure what you mean - and please explain why my lib doesn't
> solve the above issue. Thanks.

The short answer; there is no encoding specification. There is a de facto
standard; a stream of readable bytes separated into distinct records by 
newline
characters. A standard encoding would allow downstream tools (analysis
and viewing) to be much more robust and also application independent.

Cheers,
Scott