💾 Archived View for tilde.pink › ~kaction › log › 2021-03-18.1.gmi captured on 2022-04-28 at 17:24:17. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

➡️ Next capture (2023-01-29)

-=-=-=-=-=-=-

On configuration files (part 1)

Many programs use configuration files in addition to command-line options. And as programs grow and cover more use-cases, these configuration files get more complex and sometimes become limited and esthetic programming languages.

I would argue that it is deplorable practice. Instead of relying on well-known and well-understood general-purpose tools, the administrator is pushed into learning and using obscure language with low expressive power.

For example, the Apache web server contains a basic macro expansion module. This module introduces more complexity into Apache bringing no extra power to the administrator on top of what he could do with any generic text processing tool like m4 or Perl.

https://httpd.apache.org/docs/current/mod/mod_macro.html

Another example is the reference object in OpenAPI specification. The authors of the specification anticipated that any OpenAPI document would inevitably contain a lot of duplication, but their solution is unsatisfactory -- they introduced variables but not functions. A much more sound approach would be to admit that OpenAPI specification is output format and is not supposed to be written directly by humans. It would also make the specification simpler.

http://spec.openapis.org/oas/v3.0.3#reference-object

So here is my message -- stop inventing complex configuration language and start using simple formats suitable for generating. JSON covers all needs ever; in many cases, envfile is enough.

https://skarnet.org/software/execline/envfile.html

https://www.json.org/json-en.html