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

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-02-16 17:54:03

On Mon, 2009-02-16 at 20:41 +0300, Andrey Semashev wrote:
> 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.

Not mine, posix's.

> > 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?

Yes.

>  How implementing the syslog protocol in Boost.Log helps with this then?

It won't unless you do what is described below. I've been trying to
guess what it is that makes you think there needs to be the one and only
syslogd on a system that is a source of messages to be consumed by
syslog. This is one historical reason machine X syslogd collects
messages locally, say via unix domain socket, and sends them via 514 to
remote syslogd on machine Y. Y trusts X's admin and the network in
between. Of course in the real/modern world this is all just historical
nonsense.

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

My point was in reaction to your suggestion you could mix and match the
thing you refer to as the syslog API with different syslogd
implementations.

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

Agreed. As per following.

> > If instead you allow an arbitrary source port (which is fine

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

Cool. Thats all I did want. And all I didn't want was to run a syslogd
on the box the app was on. This addresses both.

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

Hmm. We seem to be in violent agreement again. We agree that portable
way to get something to any syslogd (loal or remote) is RFC3164 and we
agree that on a posix box you should use the syslog() API to log to the
local syslogd, and that boost log should support both. Excellent.

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

Never mind. It just seemed the arguments you were using re how limited
syslog API was, and hence why boost log should not be used to implement
it, were the same reasons that boost log should directly support sending
RFC3164 messages....

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

That was Peter Dimov's (2) suggestion, in effect. I like it but it isn't
as core to what I at least see the job of a logging lib as being as the
ability to send (Peter's (1)).

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

They are almost 1:1 - with pthreads offering a few extra attributes that
can be controlled.