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.