91–100 of 163 posts
I had tons of headaches trying to get toml to do what's trivial in Json (nested arrays of objects of arrays of ... etc). 1/10 would not try again. For very simple, hear "flat" config it checks out. But then, so does yaml or even ini files. Anything requiring composite types was just a nightmare. I'd even prefer xlm before using toml again.
Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss. I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating. YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration. JSON is too strict/simple.…
There are a few projects with a similar feel as json yet allowing nice to haves like comments and trailing commas: * json5 * HCl * hjson (now unmaintained)
Which is quite sad, as I thought that it was the best one (if memory serves)..
I had tons of headaches trying to get toml to do what's trivial in Json (nested arrays of objects of arrays of ... etc). 1/10 would not try again. For very simple, hear "flat" config it checks out. But then, so does yaml or even ini files. Anything requiring composite types was just a nightmare. I'd even prefer xlm before using toml again.
I never had to work with it seriously but I still don't get why people hate XML so much.
On a deeper level, I think they might be frustrated with the ability to develop custom formats (XSDs) which effectively make XML not one format, but a gazillion formats.
“Obvious” is subjective. I find TOML to be remarkably confusing and surprising and UNobvious, whereas YAML makes perfect sense to me, even though plenty of folks hate it. Essentially, the name is pretty obnoxious in multiple ways, given that it’s basically just an extension of the long-established INI format.
country: noI had tons of headaches trying to get toml to do what's trivial in Json (nested arrays of objects of arrays of ... etc). 1/10 would not try again. For very simple, hear "flat" config it checks out. But then, so does yaml or even ini files. Anything requiring composite types was just a nightmare. I'd even prefer xlm before using toml again.
I never had to work with it seriously but I still don't get why people hate XML so much.
There's plenty of room for debate, e.g. element versus attribute and things get unwieldy pretty quickly [1]
The "note"-example illustrates the issue quite well: the order of the elements matters and you end up writing every element identifier twice.
Not to mention the bloat that comes with using an XML library that's actually compliant with the standard and includes all the bells 'n whistles.
TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
Earlier quoted context omitted.
JSON should be banned for configuration, if only for the fact it doesn’t support comments.
JSON is great, but not for config: It was never really meant to be written by humans.
If it looks like text, make it as easy as possible for humans to consume and write by hand. Period.
That's a small but very important reason why HTTP rules the world.
Earlier quoted context omitted.
It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…
You're assuming that all languages have a "System.Guid" type that the configuration value can be parsed into. If you want a strongly type configuration that works across many languages, you'll need to also provide the per-language implementation of those types to fill the gaps. You'll notice that JSON, YAML, INI, and XML also do not have IP address nor GUID types. What configuration format does meet your approval?
None at the moment.
My problem with all of them is that I can't scan them visually to spot typos or mistakes. They break the content up and move related data too far apart for the inconsistencies to be immediately apparent.
Don't laugh, but in the absence of better options, I prefer to use Excel. With tabular data, things that belong together are visually adjacent. There are no repeated headers, or unnecessary syntax. Formulas are available, but hidden by default.
In the past I liked to use XML, but only with Altova XmlSpy, which had a kind of "hierarchical table view" superficially similar to Excel, but for tree-like data.
Both of the above are easy to use from PowerShell. I even wrote myself an Import-Xlsx module that works without Excel having to be installed. It uses the .NET framework libraries for opening XLSX files. (Under they hood they're essentially just a Zip file containing plain XML data.)
Ideally?
I'd like something like the SQL Server Analysis Services MDX query language, but with a front-end more like Excel for the editing of the data.
It is purpose designed for multi-dimensional data, and in my field that's exactly what I have to do: provision every combination of a bunch of tables.
For example: For each data centre, for each availability zone, for each of PRD/UAT/DEV, deploy each of the following roles, with 'n' instances each.
This is a multi-dimensional cube, also known as a full outer product.
Naively expanding everything is not good either, there needs to be some sort of language for making "exceptions". Such as: The DEV environment is only in this location. UAT has fewer sewers than PRD. Etc...
That's where a nice language would work wonders. You'd want to be able to do things like:
*.*.dev.sql.instances = 0
us-west.*.dev.sql.instances = 2
So instead you get monstrosities like the Azure ARM "copy" syntax: https://docs.microsoft.com/en-us/azure/azure-resource-manage...
TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
Because everyone would agree for 80%, but then need different 20%.That's how you end up with 10k pages specs or XML and doc types.
And if you need that just use XML, that is actually what it was designed for.