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

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-15 04:31:48

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.