Subject: Re: [boost] [log] Review-ready version in the Vault
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-02-15 07:22:26
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk