On Thu, 24 Jun 2010, Mr. Demeanour wrote: > [email protected] wrote: >> On Thu, 24 Jun 2010, Michael Biebl wrote: >> >>> Looking at the XML config example I have to admit that I don't >>> really like how it looks and feels. >>> >>> Even david's example looks rather verbose and I also share the >>> concern that such an XML file would be hard to edit using e.g. vi. >>> >>> I just stumbled upon >>> http://stackoverflow.com/questions/1925305/best-config-file-format. >>> >>> >>> One alternative already discussed here, is YAML. Then the site >>> above mentions INI style format, which basically everyone knows but >>> question is, if it's flexible enough. >> >> INI is good for one level of item->subvalue data, but with rsyslog I >> think we need the ability to go arbararily deep >> >>> Has anyone experience with JSON or LUA? >> >> both of these are really full languages (or subsets of languages). I >> don't think they are appropriate for config files (and I really >> question them as being appropriate for data transfers, even though >> JSON is used for this purpose extensivly) > > Hmmm. It struck me a few-dozen posts back in this thread that the > configfile language perhaps *needs* to be a full language. > > Many perl and PHP apps have config files that are really data > declarations in perl or PHP; I thought of suggesting a configfile > written in perl. Then I reconsidered. > > Could you elaborate your objection to using JSON? you say you "question" > it, but we haven't seen your question.
part of it is that it offends me to send data as a code snippet to be interpreted. This has already caused security issues that people are working around, but it just seems like a funamentally wrong thing to do. If speed or security are not major issues, having a config language be a snippet of code is definantly convienient and lets the person do a huge number of things that the program author never thought of (see simple event correltator for an example of this), but in rsyslog speed is a significant issue (processing multiple hundreds of thousands of logs per second doesn't leave much time) and I don't think that an interpreter is up to the task. Interpreted languages also usually don't support multi-threaded operation well. It may be possible to compile the interpeted language and then run that, but that starts to seem a bit complicated for a config language. Taking this approach would be an interesting thing to do, but I think it would end up being a pretty complete re-write of rsyslog. the approach I would take would be to start by making everything that rsyslog does into a function and then have the 'config file' define the entire event processing loop. After doing this I would look at the result and see if there are pieces that really are fixed and can be hidden from the user, making the snippets of code that remain be the 'config variables' David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
