Boost logo

Boost :

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-16 12:41:30

Darryl Green wrote:
> Now, this API, by itself is problematic. It assumes a syslogd.

All these are your assumptions. I don't see any of these functions
require syslogd or /dev/log. However, I admit that often this API is
implemented that way.

> A posix syslog() call can only log to the daemon. Daemon config controls
> distrobution from there. Now, if you enforce the syslog "security"
> mechanism that will only accept datagrams with a source port of 514, and
> you have multiple apps try to bind to 514, you will be in trouble, it
> won't work.

You mean when multiple apps run on the same machine, right? How
implementing the syslog protocol in Boost.Log helps with this then? In
fact, using the native implementation (if there is one) is more
preferable in this case, since it may use some opaque access to local
syslogd (the one that you implied in your post), that would allow
multiple apps to log simultaneously. Moreover, as this access is
provided by OS I would expect it to be authorized by security policies
that may be in action, as opposed to raw usage of port 514.

> If instead you allow an arbitrary source port (which is fine
> - in reality "restricted" source ports provide no network security) you
> can have as many independently configured sinks, each logging to any
> destination, local or remote, as you like.

> As you are obviously aware, having already implemented a sink using it,
> the syslog API (really, the RFC3164 message format) provides only very
> limited message routing/filtering fields. As soon as you rely on it to
> route messages, you have lost one of the main features of your proposed
> logging library - extensible and flexible message routing/filtering.

Ok, consider me convinced on this part. I will add portable RFC3164
support to Boost.Log, as it will help to route log records better.

>> IOW, I see the following scheme quite viable:
>> Application A links with syslog API implementation X.
>> Application B links with syslog API implementation Y.
> Err - no. Using more than one is not guaranteed to work - unless... See
> below.
>> Both X and Y send syslog messages to the daemon Z, which may or may not
>> be part of X or Y distribution. Z may be an independent project at all.
> The only publicly defined, portable interface to a syslog daemon is
> RFC3164. There is no guarantee that a given
> platform/environment/whatever you want to call it uses the same protocol
> as another to communicate between a syslog client and a local syslogd.
> Thats the "err - no" above.

Well, a "syslogd" that doesn't support RFC3164 (even from local
processes) is not syslogd as I see it. I agree that it can provide an
additional, internal interface that can be utilized by the syslog()
call. And speaking of it, for the reasons I mentioned above, it may be
perfectly reasonable to provide support for the native syslog API, if
it's available.

>> Although hypothetically it looks possible to wrap the whole Boost.Log
>> into a library that exposes POSIX syslog API, this would be a quite
>> heavy solution. The syslog API is quite simple and C-oriented, it
>> doesn't need all the bells and whistles that Boost.Log provides.
> Doesn't need/doesn't provide - aren't you arguing against your own
> objections to implementing RFC3164 logging without going through the
> syslog API now?

I'm not sure I understand you. All I'm saying that Boost.Log is too
heavy to implement the syslog API (the syslog() call, if you prefer).

Or were you talking about implementing syslogd on top of Boost.Log? If
so, then I agree, this would be quite possible.

> If you built pthreads over boost thread you would restrict its
> capabilites somewhat due to restrictions in boost thread. +/- some
> syntactic nicities, RAII etc boost thread is a subset of pthreads.

I must be missing something about pthreads, but I always thought of
Boost.Thread as of a far more flexible, while sometimes more heavyweight
instrument than pthreads.

> If
> boost log's ambitions were only to be a C++ "view" of a portable subset
> of syslog then your comparison might have some relevance (and the lib
> wouldn't get accepted).

It isn't, yet. :)

Boost list run by bdawes at, gregod at, cpdaniel at, john at