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.