4 ms·

This reminds me of the angst that came when Windows shifted from ".ini" files with clear name=value lines to the "registry", which paid many the bills of consul

by mwexler 15y ago

This reminds me of the angst that came when Windows shifted from ".ini" files with clear name=value lines to the "registry", which paid many the bills of consultants, utility programmers, and "fixit-guys" via the fun that is Regedit. +1 for more simple text files... and hey, devs: if you don't need a nested object format, perhaps even leave out the JSON or XML and just make a simple file...

Anderkent 15y ago
JSON looks pretty good even if it's a flat list, so I don't see a problem there.
- kbolino 15y ago
  Since JSON is (a subset of) YAML, and YAML was actually designed to be human-readable, I'd say it's the better choice. http://yaml.org/ http://yaml.org/
  - masklinn 15y ago
    YAML's significantly more complex (and probably harder and more expensive to parse) tough.
    - kbolino 15y ago
      I agree, and I wouldn't suggest it as your general-purpose data serialization language. However, for configuration files, which are loaded either once or at most infrequently, the cost is negligible (IMO) compared to the benefit to human readability (and comments).
  - daeken 15y ago
    Agreed! I write a lot of fuzzers and often need to represent a large API with lots of interconnections. YAML makes this trivial.
- mechanical_fish 15y ago
  One annoyance with JSON as a config-file format is that you apparently can't put comments in it. At least not out-of-band comments: http://stackoverflow.com/questions/244777/can-i-comment-a-json-file http://stackoverflow.com/questions/244777/can-i-comment-a-js... You can put in in-band comments, by defining a JSON format that has a bunch of '_comment' keys sprinkled through it, but that's annoying because you've got to design that in, and decide which elements deserve comments and which don't, and that's just a big hairy yak which sits there daring you to shave it, practically begging you to do a bunch of YAGNI up-front design of the comment protocol, and then even when you're done you still have to fret about how those keys might get misinterpreted by clients from now until the end of time. Even human readers will have to intuit the the semantics of your '_comment' key ("oh, the computer never reads this, this is just for me!"), whereas humans generally recognize the significance of real, standard comment syntaxes like # or ;; or // or what have you. Or you could use a JSON preprocessor that strips the comments, but that's a little trap that you build for yourself, because now your JSON is no longer universally-parseable by any language's JSON library. You could strip the comments at build time, but now your production JSON files on the server don't have the comments, and this is likely to be just where you need them - you put them there for the troubleshooter, who will find them at 3am when the server just crashed. But I've sometimes used JSON for these things anyway. Life is too short for perfectionism, and it is a nice clean format. Almost too clean.
  - d0mine 15y ago
    You could try YAML as a superset of JSON with comments.
    - mechanical_fish 15y ago
      Indeed. This is pretty much my plan for the future.
  - njharman 15y ago
    > can't put comments in it. Exactly! With 25 years of sysadmin / devops / whatever kids call it these days, I can attest to the fact that config files are for comments/documentation. That they happen to also configure some software is a minor side-effect.
- DougWebb 15y ago
  One drawback to JSON files, and XML files and a number of other text file formats as well, is that they allow variable formatting. That makes them difficult to work with using tools like diff, which takes away a lot of the power of version control. For example, you can take a JSON file and format it two ways: all on one line with little or no whitespace, and pretty-printed with multiple lines and indenting. Semantically, the two files are identical because they'll be parsed into the same data structure when you read it in. Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. XML suffers from this as well, and can be even worse. In some XML DTDs/schemas elements can be reordered without changing the semantic meaning of the document. I've also had this problem with CSS files, which are partially order-dependent. If you have a big CSS file with lots of rules that cover different parts of your site, there are clumps of rules that are related and must be in the right order to cascase properly, but the clumps are mostly independent and their order doesn't matter. In the past I've written tools that canonicallize formats like these just for doing diffs. It's a hassle, but it was necessary to allow my team to manage changes in shared resource files, and it worked well. Today, I'd use a tool like that as a git commit hook so that the repository always contained the format I wanted (assuming it's still usable in that format, which wasn't always the case) but back then I didn't have that option.
  - scott_s 15y ago
    Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. Granted, but the exact same problem exists for most programming languages. I don't bring this up to dismiss your complaints, but to admit I'm surprised you found it to be a problem. While you mention a technical solution at the end of your post, I figured most people handled this with a non-technical solution: agreed upon formatting guidelines.
Dylan16807 15y ago
I don't really think it's the format of the registry that causes issues. It's still a pretty simple key value at each node, and you have multiple nodes with access control much like having multiple .ini files in different places in the file system.
tonyedgecombe 15y ago
There are some benefits to the registry including fine grained control of permissions and a common model for all applications.

by mwexler 15y ago

Anderkent 15y ago

JSON looks pretty good even if it's a flat list, so I don't see a problem there.

kbolino 15y ago
Since JSON is (a subset of) YAML, and YAML was actually designed to be human-readable, I'd say it's the better choice. http://yaml.org/ http://yaml.org/
- masklinn 15y ago
  YAML's significantly more complex (and probably harder and more expensive to parse) tough.
  - kbolino 15y ago
    I agree, and I wouldn't suggest it as your general-purpose data serialization language. However, for configuration files, which are loaded either once or at most infrequently, the cost is negligible (IMO) compared to the benefit to human readability (and comments).
- daeken 15y ago
  Agreed! I write a lot of fuzzers and often need to represent a large API with lots of interconnections. YAML makes this trivial.
mechanical_fish 15y ago
One annoyance with JSON as a config-file format is that you apparently can't put comments in it. At least not out-of-band comments: http://stackoverflow.com/questions/244777/can-i-comment-a-json-file http://stackoverflow.com/questions/244777/can-i-comment-a-js... You can put in in-band comments, by defining a JSON format that has a bunch of '_comment' keys sprinkled through it, but that's annoying because you've got to design that in, and decide which elements deserve comments and which don't, and that's just a big hairy yak which sits there daring you to shave it, practically begging you to do a bunch of YAGNI up-front design of the comment protocol, and then even when you're done you still have to fret about how those keys might get misinterpreted by clients from now until the end of time. Even human readers will have to intuit the the semantics of your '_comment' key ("oh, the computer never reads this, this is just for me!"), whereas humans generally recognize the significance of real, standard comment syntaxes like # or ;; or // or what have you. Or you could use a JSON preprocessor that strips the comments, but that's a little trap that you build for yourself, because now your JSON is no longer universally-parseable by any language's JSON library. You could strip the comments at build time, but now your production JSON files on the server don't have the comments, and this is likely to be just where you need them - you put them there for the troubleshooter, who will find them at 3am when the server just crashed. But I've sometimes used JSON for these things anyway. Life is too short for perfectionism, and it is a nice clean format. Almost too clean.
- d0mine 15y ago
  You could try YAML as a superset of JSON with comments.
  - mechanical_fish 15y ago
    Indeed. This is pretty much my plan for the future.
- njharman 15y ago
  > can't put comments in it. Exactly! With 25 years of sysadmin / devops / whatever kids call it these days, I can attest to the fact that config files are for comments/documentation. That they happen to also configure some software is a minor side-effect.
DougWebb 15y ago
One drawback to JSON files, and XML files and a number of other text file formats as well, is that they allow variable formatting. That makes them difficult to work with using tools like diff, which takes away a lot of the power of version control. For example, you can take a JSON file and format it two ways: all on one line with little or no whitespace, and pretty-printed with multiple lines and indenting. Semantically, the two files are identical because they'll be parsed into the same data structure when you read it in. Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. XML suffers from this as well, and can be even worse. In some XML DTDs/schemas elements can be reordered without changing the semantic meaning of the document. I've also had this problem with CSS files, which are partially order-dependent. If you have a big CSS file with lots of rules that cover different parts of your site, there are clumps of rules that are related and must be in the right order to cascase properly, but the clumps are mostly independent and their order doesn't matter. In the past I've written tools that canonicallize formats like these just for doing diffs. It's a hassle, but it was necessary to allow my team to manage changes in shared resource files, and it worked well. Today, I'd use a tool like that as a git commit hook so that the repository always contained the format I wanted (assuming it's still usable in that format, which wasn't always the case) but back then I didn't have that option.
- scott_s 15y ago
  Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. Granted, but the exact same problem exists for most programming languages. I don't bring this up to dismiss your complaints, but to admit I'm surprised you found it to be a problem. While you mention a technical solution at the end of your post, I figured most people handled this with a non-technical solution: agreed upon formatting guidelines.

Dylan16807 15y ago

I don't really think it's the format of the registry that causes issues. It's still a pretty simple key value at each node, and you have multiple nodes with access control much like having multiple .ini files in different places in the file system.

tonyedgecombe 15y ago

There are some benefits to the registry including fine grained control of permissions and a common model for all applications.