Darryl Green wrote:
As for Boost.Log, once the POSIX API is implemented on Windows, it will be supported by Boost.Log right away.
What exactly do you mean by the vague reference to the "posix syslog API"?
From the man page I see that the API is defined in POSIX.1-2001. http://linux.die.net/man/3/syslog That is what I refer to as POSIX-compliant syslog API.
Windows (if you install SFU) has a posix API and guess what - it includes a syslogd. Similarly, you can run cygwin and install a syslogd.
Then Boost.Log already supports syslog on Windows, if you install SFU or Cygwin. I'm not sure it is an often used configuration, though.
There are also a a number of free and commercial syslogd-like tools for windows that receive logs by various means, including RFC3164, if thats what you want.
I see no need to develop another "syslogd" for windows - there are plenty already.
Yes, there are a lot of syslog servers, but I haven't seen any native client APIs, except for Cygwin. If you know one, please, tell me.
This has been a long thread of violent agreement re the undesirability of yet another syslogd afaiks.
This has nothing to do with whether boost log, claiming to be a cross platform logging library, should support generating and sending RFC3164 messages. I belive it should, as this is a (the?) major cross platform logging method, used by everything from network equipment to servers.
A useful RFC3164 sender capability would seem to require only the development of a sink able to format messages in accordance with RFC3164 and send them over UDP.
... or TCP. And, perhaps, with an encryption layer. 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 don't see any particular difficulty in implementing such a sink?
Technically, there may not be difficulties. But I don't think it's reasonable.