On Fri, 2009-02-13 at 18:12 +0100, vicente.botet wrote:
Dmitry Goncharov wrote:
syslog() generates log messages for syslogd. There is no syslogd on windows. Where do you expect the syslog backend pass the messages to?
The syslog() and syslogd are the POSIX API, which among other things allows to send log data to a remote server, using the syslog protocol, which Peter refers to as RFC3164.
RFC3164, titled "The (BSD) Syslog Protocol" defines a protocol. Quite a number of implementations of "a syslog protocol" bearing a close resemblance to the protocol described in RFC3164 existed well before RFC3164 was written. RFC3164's purpose is to provide a specification for an interoperable, cross platform way of sending log messages, implementable on the widest variety of platforms possible (essentially, any platform that can send UDP datagrams). It explicitly does not cover what the reciever of those log messages does with them. The receiver would, conventionally, be sylogd, but RFC3164 does not require that.
The syslogd daemon, as well as many other similar daemons, is capable of doing many more things with the log data than to send it via the syslog protocol.
Precisely. I see a whole lot of people saying that logging should not include a syslog daemon implementation - which seems to be a consensus view - I haven't seen anyone ask for one???
I feel that this approach may be valid for Windows, too. In particular, I think that implementing a POSIX-compliant syslog API can have its independent value. Among traditional support for RFC3164 and log files it could support Windows-specific actions, like passing log records to the Windows Event Log.
This syslogd on wondows project is all very well, but has nothing to do with boost log as proposed. It also has nothing to do with RFC3164 (beyond the fact that such a syslogd would need to include RFC3164 receiver capability).
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"? 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. 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.
I agree, it is not the responsability of Boost.Log to provide a a POSIX-compliant syslog API implementation on every platform, in particular on Windows.
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. The formatting requires extracting a priority and timestamp from the message being logged to build the header (this also requires the host name or IP and the process/program name to be known to the sink). The message content field format is freeform/not specified by RFC3164 and should simply contain a readable formatted message. I don't see any particular difficulty in implementing such a sink?