
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 seems orthogonal to me and can be handled via boost::serialization, as you suggest. What remains is the dispatching logic that brings the "blob" archive contents back from the sink to the point where they should be deserialized, that is, the source. I believe that is currently not possible with the library because there is no notion of records in the backends. At the other end of the spectrum, logging is used synonymously for documenting program activity, often in a textual human-readable fashion. In this case, there is no need to replay the contents as they are only summaries or documentation of activity rather actual data. The library in its current form is well-suited to perform the latter task but probably needs to be extended to support the former. Matthias -- Matthias Vallentin vallentin@icsi.berkeley.edu http://www.icir.org/matthias