On Mon, 19 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> 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. > > The current parser obviously creates some internal structures used by the > engine to run.
This is an incorrect assumption. the current parser creates some internal structures, but it also executes things immediatly > Is this fully documented? No, it's not fully documented because it's currently up to the individual module to do whatever it wants to do when it sees a config option. It can _do_ something, or it can create a variable that nothing else knows about, or it can change an existing variable. I initially made the same assumption, but Rainer has clarified this in these threads. David Lang > If so, what's to keep someone > from replacing the current parser with a completely different one that > builds the same internal structures? Could you not have different > configuration parsers? (issue: how to know which one to use; command line > option perhaps? the first line describing which parsing module to use (and > if missing, use the original one)?) Such a method might be beneficial to > explore alternative configuration files. > > -spc (Just an idea ... ) > > _______________________________________________ > 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
