4 ms·

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

by chx 3y ago

bayindirh 3y ago
This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI. You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.
- lpointal 3y ago
  > I don't think even though TOML has some official spec Read it on https://toml.io/ https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).
  - bayindirh 3y ago
    Oh sorry, I missed a comma. It should read: "I don't think, even though TOML has some official spec, ..." Fixed the comment too. I know TOML has an official spec.
- Brian_K_White 3y ago
  Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!
  - bayindirh 3y ago
    I used Windows 3.1 and 3.11. That's all what I'll say.
- arp242 3y ago
  > I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. Overall it's not that bad, see e.g. https://arp242.github.io/toml-test-matrix/ https://arp242.github.io/toml-test-matrix/ If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests. These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.
Brian_K_White 3y ago
Shall we bet on what would happen if we asked 10 random people of any IT stripe to write a small sample INI file? Come on.
- SiempreViernes 3y ago
  The problem isn't with the small configuration files, those are just argv put into a file. Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.
  - bayindirh 3y ago
    It'd generate same set of problems in INI, YAML, TOML, XML, JSON, BICF (bayindirh's imaginary configuration format). Because these are not related to how you write the file, but how your software operates in your mind.
    - SiempreViernes 3y ago
      How the software operates is of course dependent on the expressiveness of the configuration format, so it is clearly false in most practical senses to claim that the flat key-value format of INI and BICF will generate the same set of problems as formats that allows for list and nesting. If we accept the assertion that the complexity of a configuration file for the stated scenario is constant across all configuration formats, we will next be asserting that there's no difference in complexity between solutions in x86 assembly and LISP.
      - bayindirh 3y ago
        We're approaching from different sides. You stated a problem: Configure ~6 servers where they share variables. I can implement it in plethora of ways. The most sensible one for me is to have a general or globals or defaults area where every server overrides some part of this defaults. The file format has nothing to do with the sectional organization of a configuration file. Because none of the files force you to a distinct section organization. e.g.: Nesting is just a tool, I don't care about its availability. I don't guarantee that I'll be using if that's available. I can write equally backwards and esoteric configuration file in any syntax. Their ultimate expressiveness doesn't change at the end of the day. It can be <network iface="eno1"><ipv4_address>192.168.1.1</ipv4_address></network> or iface_eno1_ipv4_address = 192.168.1.1 or iface.eno1.ipv4.address = 192.168.1.1 I don't care. All can do whatever I want and need. Only changes how you parse and map. It's hashmaps, parsing and string matching at the end of the day. If you know both languages equally well, LISP becomes as complex as x86 assembly and x86 assembly becomes as easy as LISP. Depends on your perspective and priorities. If you don't know how to use the tool you have at hand, even though it's the simplest possible, you blow your foot off.

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

by chx 3y ago

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI. You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.

lpointal 3y ago
> I don't think even though TOML has some official spec Read it on https://toml.io/ https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).
- bayindirh 3y ago
  Oh sorry, I missed a comma. It should read: "I don't think, even though TOML has some official spec, ..." Fixed the comment too. I know TOML has an official spec.
Brian_K_White 3y ago
Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!
- bayindirh 3y ago
  I used Windows 3.1 and 3.11. That's all what I'll say.
arp242 3y ago
> I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. Overall it's not that bad, see e.g. https://arp242.github.io/toml-test-matrix/ https://arp242.github.io/toml-test-matrix/ If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests. These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.

Brian_K_White 3y ago

Shall we bet on what would happen if we asked 10 random people of any IT stripe to write a small sample INI file? Come on.

SiempreViernes 3y ago
The problem isn't with the small configuration files, those are just argv put into a file. Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.
- bayindirh 3y ago
  It'd generate same set of problems in INI, YAML, TOML, XML, JSON, BICF (bayindirh's imaginary configuration format). Because these are not related to how you write the file, but how your software operates in your mind.
  - SiempreViernes 3y ago
    How the software operates is of course dependent on the expressiveness of the configuration format, so it is clearly false in most practical senses to claim that the flat key-value format of INI and BICF will generate the same set of problems as formats that allows for list and nesting. If we accept the assertion that the complexity of a configuration file for the stated scenario is constant across all configuration formats, we will next be asserting that there's no difference in complexity between solutions in x86 assembly and LISP.
    - bayindirh 3y ago
      We're approaching from different sides. You stated a problem: Configure ~6 servers where they share variables. I can implement it in plethora of ways. The most sensible one for me is to have a general or globals or defaults area where every server overrides some part of this defaults. The file format has nothing to do with the sectional organization of a configuration file. Because none of the files force you to a distinct section organization. e.g.: Nesting is just a tool, I don't care about its availability. I don't guarantee that I'll be using if that's available. I can write equally backwards and esoteric configuration file in any syntax. Their ultimate expressiveness doesn't change at the end of the day. It can be <network iface="eno1"><ipv4_address>192.168.1.1</ipv4_address></network> or iface_eno1_ipv4_address = 192.168.1.1 or iface.eno1.ipv4.address = 192.168.1.1 I don't care. All can do whatever I want and need. Only changes how you parse and map. It's hashmaps, parsing and string matching at the end of the day. If you know both languages equally well, LISP becomes as complex as x86 assembly and x86 assembly becomes as easy as LISP. Depends on your perspective and priorities. If you don't know how to use the tool you have at hand, even though it's the simplest possible, you blow your foot off.