RE: syslog config file format poll

Hi all,

Thanks for all the great comments, please keep them coming.

I deliberately do not currently participate in the discussion because I
would like to keep my personal preference out of it. Of course, I'll do
a wrap-up once I consolidated all the feedback.

I'd like to make one exception for this question from Morty, because I
think probably a number of folks find it relevant:

> So, what does rsyslog do that syslog-ng doesn't?

Actually, as far as the config file format is concerned, I do not think
it is so much important if rsyslog or syslog-ng offers this or that
feature. So far, rsyslog has some features syslog-ng does not offer,
like the ability to use failover actions (e.g. when a tcp receiver or a
database server fails), RFC 3195 and syslog-protocol IETF draft support
and maybe another one or two. Syslog-ng has a (greater) bunch of feature
in addition to rsyslog, like native tls support or queued delivery (but
only in the commercial fork).

The bottom line, however, is that there will always be differences
between the two - after all, that is the reason both exist. I now the
medium-term plans for rsyslog. I can eventually guess rsyslog's
long-term evolution. I can do neither for syslog-ng. I think there are
also some architectural differences, including probably some differences
on the data flow.

And now I have to offer a bit of my personal opinion even though I did
not like to: I am somewhat scared to use syslog-ng format because that
would probably tie both projects together. Think: Rsyslog creates config
syntax for a feature syslog-ng does not yet have. What does syslog-ng do
when it implements the same feature. Should it be forced to use the some
config syntax...?

Rainer