> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Sunday, July 18, 2010 12:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > In theorie yes, in practice eg inside a password for a db connection. > > how hard would it be to allow quotes around the password? (if this ends > up > disallowing quotes in the password to the database, that's not too bad > a > cost) > > I'm trying to think of if there are some fairly minor changes that > could > be made that would make it significantly easier for a better parser to > be > written.
The real problem is the interface spec: whenever I change the syntax, I also (need to) change the interface spec. That is because the current spec says that everything from first non-whitespace after the filter up to LF needs to be passed to the output module. That's it... So even a minor change invalidates that interface. Given the fact that I know about at least three externally written plugins (which means probably more), I am hesitant to break that part of the spec, at least if I can avoid it. > changng the config is always a problem, but there are some problems > that > are much larger than others, and if a minor change would make it much > easier to move to a standard parser it may be worth making the breakage I agree, but only if unavoidable. As it currently looks, I think I will probably be able to generate a (decently complex) flex/bison parser that processes old and new-style (whatever it be) format. However, moving to flex/bison is considerable work, even if it were crystal-clear what we intend to do. So it sounds very appealing to me to stay within the constraints of the current parser and implement scoping with its help. That is still a lot of work, but much, much less than a full overhaul. Most importantly, it enables us to experimentally extend the config language, see how that works out in practice and *then* decide if we should really pursue that route. If so, we can than look at what exactly it takes to create a new parser subsystem. Of course, while extending the current system, we must keep an eye on potential "flex/bison grammars" and try not to introduce anything new that causes new problems. With the current proposal, I do not see any such problems. This gradual approach has the vast advantage that we get scoping into rsyslog at a far earlier time than when we did the full "right thing". However, the plugin interface will still be broken (I need the push/pop config ability plus config statement type designators), but at a far easier to fix level (from a plugin developer's PoV). > in > a 5.x or 6.x So doing this in a 6.x version sounds like a good thing, as it makes crystal-clear that some important things have changed. So I think you proposal is a very good one ;) Rainer > release (where the new capibilities are introduced so that > people can see the advantage of the breakage) > > David Lang > > > ----- Urspr?ngliche Nachricht ----- > > Von: [email protected] <[email protected]> > > Gesendet: Freitag, 16. Juli 2010 19:57 > > An: rsyslog-users <[email protected]> > > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > >>> -----Original Message----- > >>> From: [email protected] [mailto:rsyslog- > >>> [email protected]] On Behalf Of Mr. Demeanour > >>> Sent: Friday, July 16, 2010 11:33 AM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> Rainer Gerhards wrote: > >>>>> -----Original Message----- From: rsyslog- > [email protected] > >>>>> [mailto:rsyslog- [email protected]] On Behalf Of Mr. > >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog- > users > >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>>>> > >>>>> [email protected] wrote: > >>>>>> interesting, I'm not sure that anyone else realized that a > config > >>>>>> option could be split over multiple lines. > >>>>> I've banged my head on this (end-of-line comments). I believe the > >>>>> comments problem has been worked around now, but I still make > sure > >>>>> that I don't try to use end-of-line comments anywhere in my > >>>>> configs, just in case. > >>>> > >>>> That's an (one?) anomaly of the current parser. Thinking that it > >>>> would be replaced in the medium to long term, I did not care about > >>>> it. Looks like I now need to have a look ;) > >>> > >>> No big deal for me *now*, but it caused pain when I first ran into > it. > >>> Anyway, I thought you'd addressed this - about a year ago, maybe? > >> > >> I guess just mostly -- at least it boils down with actions > themselves, where > >> it is hard to handle due to the missing well-defined structure of > the string. > > > > is a # outside of quotes ever valid in an action string? > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
