Re: [boost] Boost.Log formal review upcoming

Subject: Re: [boost] Boost.Log formal review upcoming
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-01 11:35:12

On 03/01/2010 05:42 PM, Daniel Larimer wrote:
>
> On Mar 1, 2010, at 9:22 AM, Rutger ter Borg wrote:
>
>> Daniel Larimer wrote:
>>
>> [snip]
>>> It is one thing to dump data into a file, it is quite another to
>>> pull it out and do something useful with it.
>>
>> Yes, but that's not logging, is it? :-)
>
> I guess my point is that "unreadable" binary logs are just as good as
> "no binary logs".   If you make the job of logging easier, but do
> nothing on the replay (post processing) side then you really have not
> saved many users anything considering that the infrastructure
> (source/sink/filters) is practically the same.  By the time I write a
> "generic replay service", I would be one small step away from a
> "generic logging service".    The end result is that the output of
> Boost.Log is most suitable for human analysis without an eye toward
> making machine analysis easier.

Well, since the library provides no binary logging sink out of box, it 
does not provide a tool to read them. And it doesn't provide a binary 
sink because its quite difficult to develop one to be generic. I'm not 
saying there won't be one in the future, it's just not at the top of the 
list.

That said, nothing prevents you to write one for your needs. I believe 
the tools the library provides will help to do this in less time than 
that would require to build it from the ground. You get the whole 
library infrastructure as it is, all you need is to define the way to 
store log records.

Regarding the replay feature, I really don't quite understand what 
exactly this is. Is it a tool to read binary logs or something more?