Our messages seems have crossed, I am currently on dial-up. So my config
file/object model mail went out while I received that one. Please bear
this order of events in mind when you read this mail.
Rainer
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com
> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of
> Jan-Frode Myklebust
> Sent: Thursday, August 30, 2007 1:32 PM
> To: rsyslog at lists.adiscon.com
> Subject: Re: [rsyslog] mixing Property-Based Filters
>
> On 2007-08-30, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
> > What theinric posts is the current work-around for this situation.
>
> Yes, thanks.. With this work-around we should be able to do the same
> filtering we did with syslog-ng earlier :-)
>
>
> > There is nothing I can add to it - except some insight into
> the future
> > plans: we plan to support full boolean expression trees of any
> > complexity. However, the future enhanced config file format must be
> > fixed first (see my blog at http://rgerhards.blogspot.com).
>
> Thanks, I've been following your blog and have read your "config file"
> entry. I tend to agree with Seth Vidal's suggestion of a programming
> language style config. Looks very readable. But it doesn't matter too
> much.. as long as the funcionality is there :-)
I am trying very hard to find something useful. It's not easy. Some ways
look very elegant, but come at the expense that the config file actually
turns into a programming-like thing. Others are not capable to support
all of the desired features and the full power of the object model. At
times, I end up with things that look pretty much like syslog-ng, which
I do not like because I do not want to get into traps of mimicing its
config. Also, there *are* people who like rsyslog because it builds on
the old style config. For them, I'd like to keep it as simple as
possible for the basic needs. I do not say I will stick with the
old-style config: no way, that's simply insufficinet to configure the
new powerful object model. Read about the object model, and you'll see
that we will have multiple listeners which use potentially many
different *sets* of rules. In today's term, the full config file is a
single rule set. The ability to support multiple sets of rules make
sense when - in the long term - the input modules become more flexible.
For example, you will probably bind a different rule set to a file
reader than to a syslog receiver than to a SNMP trap receiver... You see
where the complexity begins? ;)
>
> Also, from the same posting:
>
> SV> For additional feature sets:
> SV> Something that syslog-ng cannot do but I've always wanted a syslog
> SV> daemon to do is store-and-forward remote logging and/or
> failover remote
> SV> logging.
>
> That would be a killer feature! I know about
> http://wiki.rsyslog.com/index.php/FailoverSyslogServer,
> but the /var/log/localbuffer needs to be flushed after recovery too...
These are two different things. What you are asking for is not *yet*
implemented. It will be called queued execution mode. And it will be
implemented as part of 3.0. If you read my blog post from the 30th,
you'll notice it is already present in the action object (by concept, of
course and you need to read very carefully to actually notice it ;)).
The bottom line is that I need to get the new object model first. I also
need to get the new threading model, because this functionality requires
two threads (one to feed the on-disk queueu, one to read it). Even when
design is finished, I can not implement it as long as I do not know how
to configure it. Now you (and everybody else) know why I am so eagerly
looking at the config file format. It's maybe a detail, but without it,
development comes to a standstil.
Rainer
>
>
> -jf
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
>