4 ms·
As far as I can tell XML config files (at least those intended to be hand-edited) have largely fallen out of favor in non-Java open source projects. I also don
by compay 17y ago
As far as I can tell XML config files (at least those intended to be hand-edited) have largely fallen out of favor in non-Java open source projects.
I also don't mind the current config file, but I've been using Apache for more than 10 years so I've probably lost all perspective at this point. Having the config file in Lua would certainly make it eaiser to automate, validate and document though.
- pilif 17y agowell... the XML approach was in fact proposed in the linked thread. mod_perl already allows for a totally dynamic configuration which should be sufficient in terms of automation. The documentation is quite perfect already and would IMHO lose quality if the syntax changes this drastically. The only point I'm willing to hand you is the validation argument, although the current parser seems to be doing a decent enough job already. No. Discussions like these feel to be motivated by artistic considerations instead of practical ones. Think of all the external documentation such a step would invalidate. Books, Tutorials, Blogs. And think of the external addon modules that would probably break because of this. Remember the 1.3 => 2.0 switch and how long that took and consider that 2.0 actually had some real advantages compared to 1.3.
- snorkel 17y ago...but not every Apache server has mod_perl. Adding mod_perl to a Rails or PHP server would eat more memory than its worth.
- compay 17y ago"well... the XML approach was in fact proposed in the linked thread." Yes, but, my point was that I see it as very unlikely to be adopted. "The documentation is quite perfect already" Sure it's well-written but "perfect" may be a stretch. Having a more consistent syntax would allow the documentation to be much more terse. The current documentation reads like a manual, which is great. What's being proposed would mean that the documentation could be presented as a manual, AND as an API. "The only point I'm willing to hand you is the validation argument" I think you should hand me "automation" as well. :-) Writing a tool that interprets a Lua config file would be trivial. Writing a tool that interprets the current Apache config is not. Anyway I'm not really advocating this change. I simply find the proposal interesting because I do a lot of programming with Lua and it's nice to see it get some high-level recognition.
- dkarl 17y agoAs far as I can tell XML config files (at least those intended to be hand-edited) have largely fallen out of favor in non-Java open source projects. I think it's too bad that people seem to be diverging towards either a crappy, barely readable data format or full-fledged programming languages. The advantage of XML is that it's a well-specified and reasonably flexible way of representing structured data. You can interpret an XML document as code (e.g., XSLT) but basically XML is just data until you say otherwise. Configuration file formats should be dumb. You shouldn't be able to program your configuration file to play chess. The only significant downside of XML is its verbose and barely readable syntax, and you don't need a configuration file that has its own byte compiler and runtime system to provide readable syntax.
- silentbicycle 17y agoWhile Lua is a programming language, it was designed to have a subset usable for data. It's very similar to Javascript / JSON, in that regard. (Lua grew along parallel lines to Javascript in many ways.) You can run it in a sandbox, remove recursion, etc., and its compiler has been optimized for reading large dumps of such data.