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

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-02-15 07:22:26

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.

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.

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.