Re: [boost] [log] Review-ready version in the Vault

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