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.