5 ms·
I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encourag
by mwfunk 10y ago
I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file.
In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do).
I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".
- throwaway_java 10y agoyeah. What kind of nut-bag edits config files using a text editor.
- SomeCallMeTim 10y ago>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans to read than XML) * Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days) Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language. [0] https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INF_file https://en.wikipedia.org/wiki/INF_file [2] https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers
- andrewflnr 10y agoGP is obviously not stupid enough to think that XML and binary are the only options. Their whole point seemed to be that they've seen enough binary blobs in practice that even XML was a welcome step up.
- flukus 10y ago> JSON (assuming everyone knows what this is) The new .net uses json, it's awful. No comments allowed and it get's pretty unreadable when you have nested configuration elements.
- ivl 10y agoI seriously think the lack of comments is a deal breaker for JSON config files for me. At least with what I'm doing now. I find myself changing configs a ton, and I love being able to simply change which blocks are commented to get what I want, without having to dig anywhere.
- SomeCallMeTim 10y agoI agree...and I found a Gulp plugin that lets me pre-strip comments from my JSON files as part of the build process. So I use JSON-with-comments, but the app only sees the stripped files.
- piaste 10y agoVSCode uses comments for every line in its settings.json file. I guess they figured it may not be correct JSON, but since they aren't sending those particular JSON files anywhere it doesn't matter?
- Perseids 10y agoJSON5 [1] is an extension to JSON that allows comments, multi line strings, additional commas at the ends of lists, and more. It has become my preferred config file format. [1] http://json5.org/ http://json5.org/
- DiabloD3 10y ago
- bane 10y agoI've mostly come across XML config files that are meant to be edited by humans in various programs that use some kind of Java framework as the back-end. I don't Java much, so I'd be hard pressed to remember the various framework names (Spring maybe?) but I remember at one point writing a Python script to de-XML the config files into something that was just a bunch of key=values, then another Python script to convert it back to the required XML. IIR on that project, the handful of config options that needed to be tweaked were spread across a dozen or so different XML files. If the framework could have just read a .txt file with key=values in it, config changes would have gone from 10 minutes to 30 seconds. I eventually just wrote a python thing that auto-deployed and configured the entire stack after asking you a couple questions. It was absurd. I believe Android development does (used to?) require lots of hand XML editing. Most of which just drives a Java code generator. I guess the tooling is better these days, but it was enough to drive me away.
- WatchDog 10y agoSpring was certainly a very XML focused framework. However it has had for a long time ways of using property files in conjunction with XML, while you would still need the XML to define your dependencies, you could have a simple property file for runtime configuration. Thankfully in newer releases and with spring-boot you can avoid XML entirely.
- Mikhail_Edoshin 10y agoConfig files are usually plain key-value pairs and, of course, using a whole eXtensible Markup Language for them is kind of overkill. But if your config files are more complex, say, you need a Makefile-like stuff, then XML is more than appropriate.
- YeGoblynQueenne 10y ago>> I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly I think it's more like, it's a text format (no matter what the op recommends) so it can be edited. If you don't want anyone editing your configuration you don't store it in a text file, right? Not to mention stuff like pom files that are explicitly meant to be edited by hand. Gods, why?
- int_handler 10y agoThere are plenty, especially in the Java and .NET worlds. To name a few: * Ant/Ivy * Maven * MSBuild * NuGet package configs