5 ms·
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexit
by foepys 6y ago
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else.
Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regard. Was it just because of the success of JavaScript and readily available JSON parsers? Because I'd argue that an INI parser is just as easy to write.
- vbezhenar 6y agoSometimes you can just add property "comment" or something like this.
- japanuspus 6y agoThis is exactly why TOML [0] is gaining traction as a simple configuration file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python is moving this way with (`pyproject.toml`). For more general data structures, remember that JSON is a true subset of YAML [1]: Switch to a YAML parser and you can start optionally adding comments to your files while still being compatible with legacy input. [0] https://toml.io/en/ https://toml.io/en/ [1] https://yaml.org/ https://yaml.org/
- rurban 6y agoYAML has too many features, and is entirely insecure. You really need a safe subset, as eg. used in the various CI's.
- jmillikin 6y ago> For more general data structures, remember that JSON is > a true subset of YAML [1] This is unfortunately not true -- try the input '{"a":1e2}'.
- eska 6y agoYaml is generally derided as too complex and transforming data in unintended ways. I see a lot of Rust programmers preferring RON over TOML because it is much less complex and doesn't have multiple ways to express the same thing https://crates.io/crates/ron https://crates.io/crates/ron
- bbotond 6y agoI hate YAML. XML and JSON have syntaxes that are very easy to learn. You basically see one example and know 99% of what you need. YAML has multiple ways of doing the same thing (eg. two array syntaxes) and is generally too "clean" looking to the point of being unreadable.
- z3t4 6y agoI load config files as JS (not JSON). And only use JSON for data serialization. In plain JS you can have comments and dont have to put quotes around properties. Not saying everyone should have a full JS parser for their config files, but its really nice.
- eska 6y agoSo you're running eval on your config data? Not feasible for external data.
- z3t4 6y agoIn module context. Then var config = require("settings.js"); My reasoning is that if you have access to change config or source code, all bets are off. Or you could parse the config in a separate vm and import the result as JSON.
- staeke2 6y agoBecause JSON was designed explicitly not to be a config format but a serialization format. For configs, use JSON5. At leatst imo seems most sane config formats are json5 these days.
- formerly_proven 6y ago> JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Do this with libvirt please and report back how it went :)
- dijit 6y agoI actually _do_ do this quite often. Often w.r.t local changes (attaching network devices or storage devices). If you fire up `virsh edit <resource>` you get a live view of the resource which can be updated in place. This is great to comment out some things and uncomment things for quick and dirty modifications. (some require a VM restart though).
- formerly_proven 6y agoThat has to be a recent change, because editing the XML used to cause it to roundtrip through libvirt, which doesn't keep the XML DOM around; anything not in the internal C structs would be removed from the files, including all comments.
- dijit 6y agoI’m not sure fully how it works internally I’m afraid. But I was doing this in 2013-2014 if that’s any indicator of timeframe.
- formerly_proven 6y agoWeird, I've done it quite recently on a Debian system and it reformatted & removed everything it doesn't know from the XML. If you Google this, it's a common issue and apparently the reason why the top-level "metadata" tag was added, because that metadata-tag is carried around as DOM, so doesn't get purged.
- necovek 6y ago
- Erlich_Bachman 6y agoINI only supports 2 levels of hierarchy? That is not equivalent.
- foepys 6y agoYou can use dots in section names. Some JSON configuration parsers use dots to traverse the hierarchy, so even the API stays the same.