Posted by hgs3 3/31/2025
In my opinion, JSON works well for data interchange, but it's overused for configuration, it's not localization-friendly, and it's too syntactically noisy. INI is simple but lacks hierarchical structures and doesn't have a formal specification. Confetti is intended to bridge the gap.
I aim to keep Confetti simple and minimalistic, while encouraging others to extend it. Think of it like Markdown for configuration files: there's a core specification, but your welcome to create your own variations that suit your needs.
In the "Material Definitions" example there are no { }. Why not? What's the difference? Is indentation significant?
I abandoned the effort, but nice to know that someone else had a similar idea. Will be trying this out!
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.
=====
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.
Suggestion, might be good to include Lua in the comparison table - since it’s also used for config as well.
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.