Subject: Re: [boost] Boost.Log formal review upcoming
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-02 13:04:32
On 03/01/2010 10:44 PM, Daniel Larimer wrote:
> I do not mean to put my requirements on this if my requirements are
> "out of scope" or to insist that such a feature is necessary out of
> the box, only that a boost logging library should be flexible enough
> to support some means of iterating over records in a log file.
I see. That is indeed an interesting view on logging. I must say, I did
not have this feature in mind while developing the library, but I think
it should be doable.
The library does not provide any tools to read log files, so depending
on the format you choose to store logs in, you'll have to implement one.
In terms of the library, this will be a log source. Depending on how you
want it, you may either make it directly invoke the signal, or pass the
read records through the library and then invoke the signal from a sink
backend. In the latter case you get an additional opportunity of
filtering and/or converting the record into another form (e.g. textual
in order to store it in a human-readable file).
> If your library assumes that ostream<< is defined for every type
> then making an assumption on boost::serialization to support such a
> feature would be a relatively minor addition.
Well, there is no such mandatory requirement. Rather, the type has to
support formatting of some kind, if a text-oriented sink is used. In the
most common case - yes, the formatting means putting it into a stream.
For binary-related sinks there is no such requirement, and the term
"consume" describes the process best. In your case, consuming may well
involve Boost.Serialization, there are no changes in Boost.Log required
to achieve that. Note however, that AFAIK, Boost.Serialization does not
have a tool for portable binary serialization, which was the main reason
I didn't bother with binary sinks myself.
> 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.
If syslog is sufficient, Boost.Log has the according sink out of box.
And there are many syslog servers out there.
If it's binary logging, then that should also be doable. Just write a
sink backend that would send packets through the network or shared
memory to another process. But in that case you'll also have to develop
the server side (which, of course may use Boost.Log to process received
> So my question is, how hard would it be to accomplish some of my
> requirements with the built in functions vs how much would I have to
> write from scratch to support it? I will look into it more, but
> perhaps someone more familiar with the package could offer an
> "estimate" in terms of hours required to implement some or all of the
> features I suggest. If they fit nicely into the framework, then I
> would likely contribute my own time to such an effort. If the
> framework starts to "get in the way" then perhaps we should consider
> the design.
Well, I can't estimate the hours, but these things will have to be made
1. A binary logging backend. Depending on your needs, it may have to
support portable encoding, network (Boost.ASIO will help here) or shared
memory (Boost.Interprocess). You may take a look on how the syslog
backend is implemented to get the idea of the amount of work.
2. A logging source that will receive or read the records. The amount of
work here depends on what you want in particular, but the logic required
by Boost.Log is quite trivial - call open_record and then push_record in
the logging core. You can look at the basic_logger class to see what
needs to be done.
The rest is all the side work, like implementing serialization for your
classes, setting up filters and sinks, arranging the signals you need, etc.