Re: [boost] Boost.Log formal review upcoming

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:

[snip]

> 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 
records).

> 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 
from scratch:
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.