> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Monday, July 19, 2010 11:21 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > 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 is absolutely right in his posting. But let me add some more explanation. Rsyslog's config parser was never "designed". We inherited it from sysklogd and it probably is one of the last remaining parts that actually have sysklogd heritage at all. It is not even a real parser, at least if you make some usual assumptions of what a language parser does. This all is part of the problem, and this also is the reason why it is considerable effort to change the way the config system operates. I'd really love to have what Sean assumes we have. This would be a big step into the right direction. But even if we had it, I don't think that would change the discussion. Even though loadable parsers could then be easily added, I doubt someone except me will ever write on. Look at the situation of message parsers and such -- while it is fairly simple to create one, most people are hesitant to do it (for output plugins it is even more simple, and there we see third parties!). A parser is not trivial, so I don't expect to see someone actually write one (vs. claim he would write one if the interface were there). I, on the other hand, have no motivation at all to write multiple parsers - just duplicated (aka wasted) effort. So the discussion about which parsers is the first (and thus potentially only) one is very vital. Just for the records: the current route probably is to stay with the current config system, introduce scoping and *then* think about how the system could be modified. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
