Subject: Re: [boost] Boost.Log formal review upcoming
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-03 12:15:06
On 03/03/2010 02:59 AM, strasser_at_[hidden] wrote:
> Zitat von Matthias Vallentin <vallentin_at_[hidden]>:
>
>> On Mon, Mar 01, 2010 at 02:44:32PM -0500, Daniel Larimer wrote:
>>> If my "requirements" fall outside the scope of 'logging' then perhaps
>>> we should define what logging means.
>>
>> Your description of logging is similar to the notion in the database
>> community, e.g., using WAL to store records on disk in order to reread
>> at a later point of time in case the main data structures are
>> inconsistent due to a crash or bug. In this scenario, I agree that a
>> logging library should offer a vehicle to efficiently transport the data
>> to a backend. The duality of writing the data out and reading it back in
>
>
> we use binary logging like that in the libraries-under-construction
> Boost.STLdb and .Persistent, and are in the process of uniting that
> system to be used by both libraries and potentially other boost libraries.
>
> this type of logging has very different requirements than logging some
> activity in human-readable form, from performance and data consistency
> viewpoints, so I'd like to know if you consider that type of logging
> within the scope of a boost logging library, and specifically within the
> scope of the proposed Boost.Log.
Like I said in another post earlier, this usage pattern fits the current
library structure quite well, as far as I can see. Ultimately I'm
willing to add binary logging (both reading and writing) to the library.
As for the replaying feature, if I see a tool generic enough that helps
to implement it on the user's side, I will surely add it to the library.
> should I review the library with that use case in mind?
You can surely have that use case in mind while taking a look at the
library. Boost.Log doesn't offer built in tools for it, but it should
not block it either.