Boost logo

Boost :

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk