> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Friday, June 25, 2010 11:33 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 25 Jun 2010, Rainer Gerhards wrote: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of [email protected] > > > > And as I said: a handler may do mach more. For example the > > InputTcpServerListe (or so) directive does not store the port to > listen to > > but rather starts up the listener -- right at *that point* in config > > processing. > > this wouldn't be a bad thing with what I was thinking of. the handler > starts up the listener with the variables as they are currently > defined. > later on the variables get changed and something else would see the new > versions. > > but since there are things changing that you know nothing about, this > won't work
I thought another while about all this. If I change the interface spec (what I need to do in any case), I can enable the plugin to keep track of such a stack for its own purposes (with a callback for push and pop). Then this becomes practical :) All in all, it seems like the discussion has brought up that a totally new config format may not be the right path. When I thought about the new config language, and thought about RainerScript for the first time, I meant that the old-style config could probably be part of the new format (see early RainerScript ABNF[1] and note productions like "old_filter"). It seem that this idea wasn't too bad. I have begun to think if there is a way to *evolve* the current config language. Thanks to the insight gained by our discussion, I begin to see such a way. If that's true, it would still be a lot of work, but I would have usable steps in the interim, what would make progress, and practical-use verification, far easier. I will try to think out the very rough idea I currently have and then provide more info or questions. But my overall assumption is that we stick what we currently have, but extend it in a way that provides scoping and do so in a way the provides as many usable interim steps as possible (without adding major work just for those steps). I hope this covers the spirit of our discussion. Thanks, Rainer [1] http://www.rsyslog.com/doc-rscript_abnf.html _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
