4 ms·

> Write your own No. No. No no no. Definitely no. I wish for a standardized configuration format so that I don't have to learn a new format for each softwa

by linkdd 4y ago

> Write your own No. No. No no no. Definitely no. I wish for a standardized configuration format so that I don't have to learn a new format for each software. At least JSON, TOML (and INI) and YAML are widely used enough so there is little chances that you don't know them.

ComradePhil 4y ago
They suggest "Writing your own" after they suggest the formats you mention and they clearly do not recommend it if anything else works for you: > If for some reason a key-value configuration format doesn’t meet your needs, and you can’t use a scripting language due to performance or size constraints, then it might be appropriate to write your own configuration format. But if you find yourself in this scenario, think long and hard before making a choice that will not only require you to write and maintain a parser but also require your users to become familiar with yet another configuration format.
- linkdd 4y ago
  The question I must ask then is: When does a key-value configuration format not meet your needs? Using a scripting language is still about setting key/values. No, I claim that writing your own is *never* an appropriate choice. So "think long and hard and then say no".
  - giaour 4y ago
    Sometimes you need to support something more flexible than JSON but just can't hand your (non-dev) users all the footguns that come with a Turing complete configuration language. "Key/Value" makes the problem sound simple, but maybe you're writing a rules engine, and the values are expressions that will be evaluated at runtime. It's uncommon, but the need isn't impossible to imagine. I'm personally of the opinion that using a scripting language is the worst option. Going that route is giving up on most forms of static analysis, since you can't inspect configuration values without executing untrusted code.
    - linkdd 4y ago
      Expressions that will be evaluated at runtime are just strings, no? {"rules": [ "x > 1", "x % 2 = 1" ]} So you will have an "expression parser" to parser your rules, validate them, and execute them. But at least you do not have the edge cases of everything else.
      - kevin_thibedeau 4y ago
        This sort of hack with control logic was done in XML with Ant. It was a bad idea then and it still is.
      - _gabe_ 4y ago
        At this point you're already writing your own parser to parse the expressions from the strings. Why not cut out the json completely and make it way more readable? rules = [ x + 1, x % 2 == 1 ]
      - giaour 4y ago
        Those are simple expressions (no multiline blocks, no named symbols, no expressions that call other expressions), and you're still forced to treat them as opaque strings when you use a serialization language for configuration. That may be the best approach for a given project! But if you're using configuration to define an API contract, cloud infrastructure, or a query, you might be better off using a purpose-built DSL like protocol buffers, HCL, or SQL, respectively. That approach can let you define a greater level of expressivity than is allowed in a serialization language like JSON or XML without letting config authors write scripts of arbitrary computational complexity (like they would be able to with config in a scripting language).
    - lmm 4y ago
      > Sometimes you need to support something more flexible than JSON but just can't hand your (non-dev) users all the footguns that come with a Turing complete configuration language. "Key/Value" makes the problem sound simple, but maybe you're writing a rules engine, and the values are expressions that will be evaluated at runtime. It's uncommon, but the need isn't impossible to imagine. > I'm personally of the opinion that using a scripting language is the worst option. Going that route is giving up on most forms of static analysis, since you can't inspect configuration values without executing untrusted code. Sounds like the original case of the "inner-platform effect". A "custom configuration file" format for a "rules engine" is a scripting language - you will almost certainly make it accidentally Turing complete even if you were trying not to - and it's one that's even less susceptible to analysis than a standard scripting language. The least-bad solution is an "inner" DSL in your language, IME, with lots of support code to make it as nice as possible (admittedly my experience is mainly in languages that make this easy) - that way you get tooling for free and you can leverage existing static analysis tools. Yes, your users will find ways to shoot themselves in the foot, but they were always going to.
Akronymus 4y ago
For me personally, I'd love for S-Expressions to be a standard configuration language. Sadly, it is a chicken and egg problem.
benibela 4y ago
I also thought writing my own format would be a bad idea So I choose a standardized configuration format: JSON Now I store my config in JSON, and wrote a JSON parser Unfortunately my JSON parser threw an exception when parsing floating point numbers, and my app did not start anymore. I also wrote an XML parser. In hindsight, it would have been much better to store my config as XML, since there are no floating point numbers. Parsing floats is incredible complicated.

by linkdd 4y ago

ComradePhil 4y ago

They suggest "Writing your own" after they suggest the formats you mention and they clearly do not recommend it if anything else works for you: > If for some reason a key-value configuration format doesn’t meet your needs, and you can’t use a scripting language due to performance or size constraints, then it might be appropriate to write your own configuration format. But if you find yourself in this scenario, think long and hard before making a choice that will not only require you to write and maintain a parser but also require your users to become familiar with yet another configuration format.

linkdd 4y ago
The question I must ask then is: When does a key-value configuration format not meet your needs? Using a scripting language is still about setting key/values. No, I claim that writing your own is *never* an appropriate choice. So "think long and hard and then say no".
- giaour 4y ago
  Sometimes you need to support something more flexible than JSON but just can't hand your (non-dev) users all the footguns that come with a Turing complete configuration language. "Key/Value" makes the problem sound simple, but maybe you're writing a rules engine, and the values are expressions that will be evaluated at runtime. It's uncommon, but the need isn't impossible to imagine. I'm personally of the opinion that using a scripting language is the worst option. Going that route is giving up on most forms of static analysis, since you can't inspect configuration values without executing untrusted code.
  - linkdd 4y ago
    Expressions that will be evaluated at runtime are just strings, no? {"rules": [ "x > 1", "x % 2 = 1" ]} So you will have an "expression parser" to parser your rules, validate them, and execute them. But at least you do not have the edge cases of everything else.
    - kevin_thibedeau 4y ago
      This sort of hack with control logic was done in XML with Ant. It was a bad idea then and it still is.
    - _gabe_ 4y ago
      At this point you're already writing your own parser to parse the expressions from the strings. Why not cut out the json completely and make it way more readable? rules = [ x + 1, x % 2 == 1 ]
    - giaour 4y ago
      Those are simple expressions (no multiline blocks, no named symbols, no expressions that call other expressions), and you're still forced to treat them as opaque strings when you use a serialization language for configuration. That may be the best approach for a given project! But if you're using configuration to define an API contract, cloud infrastructure, or a query, you might be better off using a purpose-built DSL like protocol buffers, HCL, or SQL, respectively. That approach can let you define a greater level of expressivity than is allowed in a serialization language like JSON or XML without letting config authors write scripts of arbitrary computational complexity (like they would be able to with config in a scripting language).
  - lmm 4y ago
    > Sometimes you need to support something more flexible than JSON but just can't hand your (non-dev) users all the footguns that come with a Turing complete configuration language. "Key/Value" makes the problem sound simple, but maybe you're writing a rules engine, and the values are expressions that will be evaluated at runtime. It's uncommon, but the need isn't impossible to imagine. > I'm personally of the opinion that using a scripting language is the worst option. Going that route is giving up on most forms of static analysis, since you can't inspect configuration values without executing untrusted code. Sounds like the original case of the "inner-platform effect". A "custom configuration file" format for a "rules engine" is a scripting language - you will almost certainly make it accidentally Turing complete even if you were trying not to - and it's one that's even less susceptible to analysis than a standard scripting language. The least-bad solution is an "inner" DSL in your language, IME, with lots of support code to make it as nice as possible (admittedly my experience is mainly in languages that make this easy) - that way you get tooling for free and you can leverage existing static analysis tools. Yes, your users will find ways to shoot themselves in the foot, but they were always going to.

Akronymus 4y ago

For me personally, I'd love for S-Expressions to be a standard configuration language. Sadly, it is a chicken and egg problem.

benibela 4y ago

I also thought writing my own format would be a bad idea So I choose a standardized configuration format: JSON Now I store my config in JSON, and wrote a JSON parser Unfortunately my JSON parser threw an exception when parsing floating point numbers, and my app did not start anymore. I also wrote an XML parser. In hindsight, it would have been much better to store my config as XML, since there are no floating point numbers. Parsing floats is incredible complicated.