What is this TOML?Visualizer:https://toml-to-json.orchard.blog/Code:https://github.com/orcharddweller/toml-to-jsonTOML spec:https://toml.io/en/v1.0.0#TOML #t...
TOML and YAML both have the problem that if you receive an incomplete document, there’s a decent chance you can’t tell. JSON doesn’t have that because of the closing curly.
It’s not a responsibly of the format, so, at most, it’s a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question
What about processes that terminate before writing the whole thing? You can’t protect against everything. Blame other processes all you want but the language spec allows for confusion.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
TOML and YAML both have the problem that if you receive an incomplete document, there’s a decent chance you can’t tell. JSON doesn’t have that because of the closing curly.
Good point, I’d been interested in using toml
Doesn’t YAML have a (seldom used) feature of a start and end of document marker? The “YAML frontmatter” that a few markdown documents have, uses this.
On the other hand, I hate that with JSON you can only store one document per file.
Some programs allow you to omit the outside braces, others require it.
But I do hate toml, and I don’t much like yaml either (why are there like 8 whitespace permutations?!)
What’s wrong with TOML? I personally think it’s great for configuration purposes.
One thing you can run into is that nesting things is hard in TOML: https://stackoverflow.com/questions/48998034/does-toml-support-nested-arrays-of-objects-tables
The syntax is simply not built for that, because
.iniformat.That’s not a problem of a format and should be handled by transport or storage.
It very much is an aspect of the format. You may deem it unimportant, but it’s a feature that is missing from toml and yaml.
It’s not a responsibly of the format, so, at most, it’s a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question
What about processes that terminate before writing the whole thing? You can’t protect against everything. Blame other processes all you want but the language spec allows for confusion.
You just check the exit code, no? The other process may fail while generating syntactically correct data too, regardless of format.