Re: [boost] Boost.Log formal review upcoming

Subject: Re: [boost] Boost.Log formal review upcoming
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-03-02 07:12:06

Daniel Larimer wrote:
> On Mar 1, 2010, at 1:03 PM, Matthias Vallentin wrote:
> > On Mon, Mar 01, 2010 at 12:03:57PM -0500, Daniel Larimer wrote:
>
> Lets assume you have a data source (boost::signal) and you connect it
> to a chain of filters that add meta data and ultimately a
> filter that converts
> the types into an archive and finally one that buffers
> "archives to disk".  Another
> filter would simply take an archive and ultimately reproduce
> a boost::signal.

As I see it, you would like there to be a reader corresponding to every log writer so that you could recover the elements used to form the original log entry, filter them just as they could have been filtered originally, and then pass them to a different sink/back end (whatever terminology the candidate library uses -- I haven't looked yet) that can create a boost::signal or other behavior.

I've never wanted to do that sort of thing with logging output -- we typically avoid logging enough to recreate an object -- so I wonder how widespread that need is.  It seems plausible, but is it appropriate and worthwhile?

> But I contend that for many people they simply want to say
> "log this signal to this file under this name" and then
> open their log and say "replay signal with name to this slot"
> and then iterate through
> the log entries possibly in a multiple of real time.  This

I don't know where those "many people" are, but I haven't met them.  For our replay purposes, we replay the system inputs, not its reactions.

> opens up a ton of existing code which is already
> separated into "producer / consumer" or "model / view"
> paradigms via signals to logging and visualization of logged
> data without
> adding any new dependencies to the original code.

This is an interesting view of logging, to be sure.

> Another reason to support this kind of function is when
> logging a large amount of data at high data rates.... binary
> files would be an order of magnitude smaller, result in less
> disk access, and use less "formatting" overhead than text
> files.  Yet it should be "trivial" to convert a binary log to
> a text log simply by using the    source => serialization =>
> binary file  => binary to obj =>  text sink.

That's an interesting idea.

> One last consideration is that often there is a desire to
> separate logging into a separate process that can
> optionally "connect" to the logging core and possibly perform
> some additional filtering on the other side of
> a socket.

Anything that offloads work from the process/thread doing the logging is useful if it doesn't introduce locking or I/O overhead that makes matters worse.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.