Re: [boost] [log] Release candidate 1 usage question

Subject: Re: [boost] [log] Release candidate 1 usage question
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-03-11 11:56:06

On Mon, Mar 11, 2013 at 7:00 PM, Alex Perry <Alex.Perry_at_[hidden]> wrote:
> Hi,
>
> I've been following with interest the development of this Log v2 code which looks very useful. However having read through the documentation I can't see any easy way of solving the following issue.  I'm wondering if I'm just missing something obvious so thought I'd ask.

I'm sorry to say that Boost.Log currently doesn't have any built in
components for interprocess logging. This is definitely the area for
further improvement of the library, although there are complications
in how to make it generic enough.

The typical solutions with the current Boost.Log are:

1. Use syslog with the appropriate daemon setup.
2. Use a text ostream sink backend with a TCP stream from Boost.Interprocess.
3. Create a custom sink backend.

The first solution does not allow to apply server-side filtering on
clients, which is unfortunate. The upside is that you don't have to
write the server or the sink backend. The other two solutions require
to write a custom server that will receive and process records from
clients.

As for the feedback from the server to the clients, this will have to
be implemented from scratch as well. The logging core, filters and
formatters cannot be placed into shared memory or serialized to a
stream, so they would have to be serialized and sent to clients
somehow. One possible way is to use a shared memory segment for this
purpose, but that implies that all processes work on a single machine.
The shared memory segment can contain a map of settings you want to
pass from server to all clients. Logging filters can be represented by
strings, similar to those you use in config files, so you can parse
them with the library in clients. Sorry, there's little the library
can offer in this regard.