On 03/03/2010 02:59 AM, strasser@uni-bremen.de wrote:
Zitat von Matthias Vallentin <vallentin@icsi.berkeley.edu>:
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.