Mr. Demeanour wrote: > > 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. > Apologies for commenting on my own post.
I note the objections to XML as a configuration language. Generally these seem to be concerned with the difficulty of reading and editing XML "as she is wrote", i.e. a UTF-8 document full of <> crows-feet, with tags, attributes, processing-instructions, namespace-declarations and all that. I'm not sure if I'm being technically correct; but the essence of an XML document is a DOM tree, not any specific rendition of that tree. Given some restricted XML-based notation (such as the notation for an rsyslog configuration, for example) there's no intrinsic reason why the XML document shouldn't be 'flattened' for storage, and represented as something like an INI file. For config data, I favour flatness. I don't think it's at all a good idea to be able to express if/then/else constructs in a config file; that belongs in the code. The configuration should be a static thing. So if XML is convenient because the DOM structure is convenient (e.g. allowing easy 'grafting' of document fragments), one could read data from a flatfile representation into a DOM during config file parsing, and modules could query the DOM to find out how they are configured. The use of a DOM internally doesn't compel the use of standard textual XML notation for the config file itself. Sorry (again), if I've missed the point. -- Jack. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
