Re: [boost] Boost.Log formal review upcoming

Subject: Re: [boost] Boost.Log formal review upcoming
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-03-01 12:03:57

On Mar 1, 2010, at 11:35 AM, Andrey Semashev wrote:

> 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.
Using Boost.Serialization creating binary logs could be made very generic.

> 
> 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.
> 
This is certainly true, the library may provide a good base from which to build binary logging.  I will need to do further research to determine how effective this could be.

> 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?

If you change the abstraction to nothing but a stream of data packets of "some type" that flows from "some source" through various "filters" to "one or more" destinations, then a "log file" becomes little more than a "buffer" in the stream.  

Thus, if you have some "real time monitoring tools" that can be hooked up to debug then these tools should be agnostic to whether or not the channel they receive their data on is from the original source or from the other side of a "log file filter".  

> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost