It clearly competes with JSON.
I think I would still much rather use JSON5 over this. It's quite similar in terms of structure and terseness, but I don't have to learn anything.
// This is a comment.
{
probe_device: ["eth0", "eth1"],
users: [
{
user: "*",
login: "anonymous",
password: "${ENV:ANONPASS}",
machine: "167.89.14.1",
proxy: {
try_ports: [582, 583, 584],
},
},
{
user: "Joe Williams",
login: "joe",
machine "167.89.14.1",
},
],
}
Top marks on the name!
Call it j5on
The first paragraph says:
[...] It is minimalistic, untyped, and opinionated. [...]
but then under "Notable features" it begins with a big bold *Unopinionated*, so that was very confusing.
Good to see a push towards less syntactic overhead, which is still considerable in JSON.
[1] https://en.wikipedia.org/wiki/Comparison_of_data-serializati... [2] https://rigaux.org/language-study/syntax-across-languages.ht...
> Confetti source text consists of zero or more Unicode scalar values. For compatibility with source code editing tools that add end-of-file markers, if the last character of the source text is a Control-Z character (U+001A), implementations may delete this character.
I’ve heard of this once, when researching ASCII control codes and related ancient history, but never once seen it in real life. If you’re insisting on valid Unicode, it sounds to me like you’re several decades past that happening.
And then given that you forbid control characters in the next section… make up your mind. You’re saying both that implementations MAY delete this character, and that source MUST NOT use it. This needs clarification. In the interests of robustness, you need to specify what parsers MUST/SHOULD/MAY do in case of content MUST violations, whether it be reject the entire document, ignore the line, replace with U+FFFD, &c. (I would also recommend recapitalising the RFC 2119 terms. Decapitalising them doesn’t help readability because they’re often slightly awkward linguistically without the reminder of the specific technical meaning; rather it reduces their meaning and impact.)
> For compatibility with Windows operating systems, implementations may treat the sequence Carriage Return (U+000D) followed by Line Feed (U+000A) as a single, indivisible new line character sequence.
This is inviting unnecessary incompatibility. I recommend that you either mandate CRLF merging, or mandate CR stripping, or disallow special CRLF handling. Otherwise you can cause different implementations to parse differently, which has a long history of causing security problems, things like HTTP request smuggling.
I acknowledge this is intended as the base for a family of formats, rather than a strict single spec, but I still think allowing such variation for no good reason is a bad idea. (I’m not all that eager about the annexes, either.)
Most existing formats are really bad for at least one of these. Tables in JSON have tons of repetition. XML doesn't have a clear and obvious way to do maps. Almost anything other than XML is awkward at best for node trees.
Confetti seems to cover maps, trees, and non-nested lists really well, which isn't a combination any other format I'm aware of covers as well.
Nested lists and tables seem like they would be more awkward, though from what I can tell "-" is a legal argument, so you could do:
nestedlist {
- { - 1 ; - 2 }
- {
- { - a ; - b }
- { - c ; - d }
}
}
I think a table could be done like JSON/HTML with repeated keys, but maybe also like:
table name age favorite-color {
row Bob 87 red
row "Someone else" 106 "bright neon green"
}
In any event, I love seeing more exploration of configuration languages, so thanks for sharing this!
My number 1 request is a parser on the documentation page that shows parse tree and converts to JSON or other formats so you can play with it.
One thing I didn't understand is this example on the homepage:
> password "${ENV:ANONPASS}"
The spec doesn't seem to mention any ${}. Is this for the program to manage rather than the parser of the config going out to fetch an env var? If so, I find this a bit out of scope to show; at least, it confused me about whether that's built-in/supported syntax or if it's just a literal with syntax intended for a different program
Depending on how set in stone this is, another complaint I might have is that you still have the trailing comma issue from JSON, except it's not a comma but a backslash (reverse solidus, as the spec calls it—my mobile keyboard didn't even know that word). Maybe starting a list of arguments with [ could allow one to use any number of lines for the values, until a ] is encountered?
"Reverse Solidus" is the Unicode name for the character [1], so if you don't like the name, blame Unicode :)
I hadn't thought of using '[' and ']' for multi-line directives, that's an interesting suggestion. It vaguely resembles arrays as they appear in various other languages. It fits with Confetti's design of, ultimately, being user interpreted.
example.com {
root \* /var/www/wordpress
encode
php_fastcgi unix//run/php/php-version-fpm.sock
file_server
Blah blah blah it doesn't have a spec. Lack of a spec doesn't matter from the user's POV in this problem domain, as all configuration files are categorically application-specific anyway. It doesn't matter to the developer either, insofar as whatever implementation you use fits your needs. This isn't object notation, it's not data interchange, it's configuration.
https://github.com/hashicorp/hcl?tab=readme-ov-file#informat...
So if the config format has its own type system you then have to convert between config types and language types
If the config type doesn't map exactly onto the target lang type you either ignore it and accept some values won't round-trip cleanly or without error, or you fall back to using strings (e.g. various possible integer type sizes, signed/unsigned etc, or decimal values via JSON)
Not saying it's always the right choice, but I can see why having lowest common denominator stringly-typed values as the config format can be seen as a feature allowing you to define the type system that the config will be parsed under to suit each particular application
Because when saying defaulting back to string and thatfor ignoring typing, wouldnt that just be the same as beeing typeless? Therefor doesn't every format support string therefor supporting typeless?
Also, in how many cases do you need to parse the same configuration in multiple different languages?
Im not saying its not useful - i just try to get the use case for this arguments.
Neo4j uses 128 bit ids. The JSON API retrieves these ids as strings of digits, Python library reading this JSON decided to interpret these as double precision floats. And sometimes it works, other times: not so much...
The whole selling point of configuration formats is to allow multiple languages to access the same data. So, cases when multiple languages have to read the same configuration format are exceedingly common.
The fact that the format supports other types means that someone (probably not you) will use those types, and then (probably you) will have to deal with the mess created by that person. I don't trust programmers in general to write good code... if possible to prevent them from writing bad code, then why not?
And well - if anyone trusts external coders he should be damned (or isnt he already for doing so? never trust external data - the golden rule...)
Your case is interesting, i worked with Neo4j years ago in a PHP project and never run into such issues, but maybe i was just lucky.
Nowadays i code mostly golang and im always making sure that whatever an external party sends me is what im expecting (validation ...).
To your point of preventing somebody to write bad code - i've given up on that. Whenever i thought the environment will enforce someone to write proper code, people proof me to be wrong be finding new ways to do the most absurd things.
But ye, its worth a try.
So - why i question such a thing? Because i'm not a fan of adding more and more 3'rd party dependencies to my projects. And while confetti might be a good thing (i never said it can't be) it wont get into any default packaging in a forseeable future meaning i have to make sure that the dependency stays stable which adds another task and liability on my end. So instead of having to deal with the devil i know (validating json data) i have to deal with a new one to eliminate the old one.
Time will tell if confetti will make its way into stable reliable state for common languages - than i might give it a try.
I know for sure I'd like "timeout: 1h6m10s" more than "timeout: 3970". So unless you want to support really specific datatypes just being typeless is better. Putting everything in double quotes to get a string, while spec-wise would be typed, is not enough when the backing data type is not going to be a string. So you might as well throw it away and let the program handle all type conversion.
Tho the quote for string argument i can't fully agree on. While sure in for example a json i would have to quote the values if i want them "typeless as string" - tho json is far supported everywhere and i'm able to interpret the parsed string values in whatever way i want to.
Adding a new dependency (confetti parsing) to spare out quotes doesn't seem to be worth the convenience to me.
Tho - both probably very subjective things to me.
Though I'm not sure why using keywords like `true`, `false` or `null` are seen as a negative. Especially the numeral digits, its the system that most of the world uses...
That said comment starting with a diese and curly brackets to group, as well as double quote for string delimiters are not that neutral on this side.
Are there any examples of what's possible with extensions?
if (x > y) {
print "x is greater than y"
}
The "punctuator arguments extension" is the one I'm most anxious about since it might be too flexible, but I'd like to hear feedback. It lets you define your own domain-specific punctuators for your configuration so, for example, you might decide that "=" is a punctuator which means the following is equivalent:
x = 123
x=123
The "comment syntax extension" is just C style comments.
My goal was to keep the language basic while encouraging custom flavors. If an extension becomes ubiquitous, then - depending on what it is - it might merge with the standard or be added to the annex.
In the "Material Definitions" example there are no { }. Why not? What's the difference? Is indentation significant?
Suggestion, might be good to include Lua in the comparison table - since it’s also used for config as well.
I abandoned the effort, but nice to know that someone else had a similar idea. Will be trying this out!
XML still works well as a configuration format.
Is it verbose? Very much so, but it ticks all the boxes:
- No ambiguity
- Typed
- Quick to parse
- Has Schemas that allow validation
- Widespread tooling support
All we needed was for applications to publish their XML schema files and any XML tool could allow for friendly editing.
eh ...
Okay, maybe it's quick. But it's also surprisingly hard to do "right". Just look at libexpat. Sure, many issues could be prevented with another programming language. But there are still regular updates because parsing custom entities is a minefield.
That said, I also like XML for all the other reasons you mentioned. Just don't do it like Maven.
This allows really cool things, like modular configs where one "main" config file can include multiple specific-purpose configs. One file can contain the "default users" while another can contain additional users, for example. Or each user can get its own file.
I'd take Prolog without I/O and (some? all?) extra-logical predicates as configuration language. Maybe if there's a way to require recursion to terminate, that'd be great, but not essential.
=====
Forbidden Characters
Forbidden characters are Unicode scalar values with general category Control, Surrogate, and Unassigned. Forbidden characters must not appear in the source text.
White Space
White space characters are those Unicode characters with the Whitespace property, including line terminators.
For example, you’ve reintroduced the Norway Problem. https://news.ycombinator.com/item?id=36745212
And I personally hope to never edit another file which lacks a strict schema like this does.