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. Is this fully documented? 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
