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-15 08:27:01

Peter Dimov wrote:
> Andrey Semashev:
> 
>> Yet again, I consider syslog as an API, not just some protocol. This 
>> API is also standardized and can be used outside of Boost. I think 
>> that having this API on Windows has an additional benefit. Therefore I 
>> think it should be implemented as a separate project.
> 
> I think I see where you're coming from: you consider the syslog function 
> a frontend to the syslogd daemon and, from your point of view, a "sink".
> 
> This is, on its surface, reasonable, but it ignores the use cases:
> 
> 1. How do I write a program that can be configured to send RFC3164 
> messages to a specific machine?
> 
> 2. How do I port a program that uses the syslog function to Windows?
> 
> Regarding (1), your proposed solution is for people to require their 
> users to install a syslogd daemon for Windows. This is unacceptable for 
> various reasons. A program that can perform its functions from user 
> space should not install a Windows service, and it would be difficult to 
> coordinate several such programs to not install conflicting syslogd 
> services.

I don't see how including syslog API implementation into Boost.Log can 
help you with this.

You will have to install the syslog daemon somewhere anyway. If not on 
the machine where your application runs, then on some remote server. And 
I think that any conflict between several applications using different 
syslog implementations is not relevant to Boost.Log and at least is 
solvable as long as there exists a single daemon that conforms to the 
syslog protocol specification. This daemon can be used for multiple 
applications. IOW, I see the following scheme quite viable:

Application A links with syslog API implementation X.

Application B links with syslog API implementation Y.

Either of the applications A or B may or may not use Boost.Log.

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.

There are plenty of Zs already, including the Windows platform. I've 
found an example of X or Y here:

http://syslog-win32.sourceforge.net/

Why would I need to include this functionality into Boost.Log?

> An alternative might be to implement syslog.lib that does whatever 
> syslogd does, but from user space. But this duplicates a significant 
> portion of the Boost.Log goals and functionality; it is effectively a 
> direct competitor to Boost.Log.

I never suggested reimplementing syslog daemon in a user-space library. 
I agree that this is quite pointless, especially since there are 
implemented daemons out there.

> Regarding (2), it makes perfect sense for Boost.Log to offer a 
> boost::syslog function as a frontend. This makes porting easy and allows 
> the program to use Boost.Log's features to centrally filter and route 
> the log messages.

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. 
Besides, it occurs to me that syslog API is a low-level instrument, and 
Boost.Log should build on to of it. Imagine for a moment that Pthreads 
are implemented over Boost.Thread - it looks quite odd to me.

Therefore applications that are explicitly tied with syslog API are 
better to be ported with a simple and straightforward implementation of 
this API, like the one I posted above.