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-16 07:36:58

On Sun, 2009-02-15 at 12:31 +0300, Andrey Semashev wrote:
> 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.
> 

Fair enough. But like any/many small interfaces to the beast that is the
posix system model, you can't really consider it in isolation. It makes
all sorts of assumptions about the platform/environment (some are
largely historical on any platform now).

> > 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.
> 

Only if you build your app against cygwin or SFL. If you don't, but you
write a triavial app that sends RFC3164 messages (actually, given
RFC3164s preference to make an effort to log anything at all, that might
as well be "any chunk of text") over UDP to localhost:514 you should see
- log messages!

> > 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.
> 

You can't separate the client and server impl unless you put an open
interface in between RFC3164 is that interface. Use it!

> > 
> > 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.
> 

What logging standard/spec/protocol/system are you refering to? There is
no such facility for syslog. There is no such facility in RFC3164.
Nobody has asked for it. TCP for log messages is a bad idea. Don't send
syslog over insecure channels. Use IPSec.

> 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

You and I have a very different view of "protocol" and "API". The tiny
bit of spec that is the man page for syslog is "just an" API. RFC3164 is
a (small and simple) protocol but still provides a far more detailed
specification of interface and behaviour.
 
>  
> having this API on Windows has an additional benefit. Therefore I think 
> it should be implemented as a separate project.
> 

I don't know who you are trying to convince re the syslog API on
windows. Who asked for it/wants it and/or isn't satisfied with existing
solutions?

> > 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.

What isn't reasonable? To provide apps with the ability to log to what
is probably the most widely deployed remote logging system in the world
without installing some service/daemon?

Is it unreasonable to ask for remote logging sender functionality to be
hightly portable - to any platform with BSD-style sockets API, without
any reliance on some syslogd being installed?