321–330 of 457 posts
I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…
Earlier quoted context omitted.
I often hear the “comments aren’t supported” argument against JSON, but as a daily consumer, creator, and maintainer of JSON, I honestly can’t recall ever _really_ needing comments in JSON. It tends to be somewhat self documenting in my experience.
When maintaining a JSON file, did you ever happen to wonder why a particular value is what it is? This is where comments belong.
I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…
For the love of god, if anyone reads this, please don't do this! Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc. API-driven configuration has none of these properties. Some Java application servers take this approach of API-driven configuration. It's an improvement over UI-driven configuration, which is what they had before. But it's still si…
If you need runtime reconfiguration in production, then it requires a runtime config management system tailored for operations folks with proper authn/authz, audit logs etc. This is a product by itself. The connection between your running program and the runtime configurator has to be intentional, secure etc.
IMO, config variables should have following bindings: 1. config variable in code. 2. program start env variable. 3. program start command argument flag. 4. runtime configuration.
All available configuration options are declared in the code. But not all configuration options should be accessible from #2 to #4. And the override preference order may not be same for all types of configuration variables.
Btw, this isn't related to Java or any particular programming language. I've seen this done in large C++ projects 20 years ago.
Earlier quoted context omitted.
TOML?
Can't recommend TOML enough. I use it for everything. Super simple and easy to edit. It fulfills all of the requirements. There are several available C++ TOML parsers, including one from Boost.
https://noyaml.com/ YAML is bad. Every YAML parser is a custom YAML parser. https://matrix.yaml.io/valid.html
Earlier quoted context omitted.
My vote is yes. Most configuration doesn’t need anything more sophisticated than key-value pairs, perhaps with namespaces. INI can manage that and TOML is basically a better-specified INI.
No reason to use INI over TOML. INI doesn't even have a standard specification.
The issue is, I think most people (myself included) enter YAML into their lives as basically a JSON alternative with lighter syntax. Without really realizing, or perhaps without internalizing, the rather ridiculous number of different ways to represent the same thing, the painful subtle syntax differences that lead to entirely different representations, the sometimes difficult to believe number of features that the l…
I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?
Earlier quoted context omitted.
When maintaining a JSON file, did you ever happen to wonder why a particular value is what it is? This is where comments belong.
If it's that important and complex, have an accompanying README that lists line numbers and comments.
Earlier quoted context omitted.
k8s and helm is where I learned to dislike yaml. I now want a compiled and type safe language that generates whatever config a system needs. I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.
Helm 3 is moving to Lua, that may be better or worse.
As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). There still has to be a standard text format, but only for the source from which the live configs have to be built. Done right, this has several advantages: 1. Built-time validation (or at least type checking). 2. Built configs can be easy to parse but (potentia…
SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.
Someone mentioned protobufs, maybe with something like those one could have both?