Re: [boost] [log] Review-ready version in the Vault

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-02-14 20:37:44

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?