Use a more capable and formal config format?

[dentarg]

Like https://toml.io/en/

Motivation

• more features like lists (arrays)
• clear how to parse it, for usage outside of LavinMQ

[dentarg]

Some comments from our friend Claude

❯ What do you think about the use of the INI format?

● INI is a solid choice for this project. A few observations:

Fits well because:

• LavinMQ's config is flat key-value pairs with a handful of sections (main, tls, clustering, etc.) — exactly what INI is designed for
• Crystal has a built-in INI parser, so zero external dependencies
• Easy for sysadmins to edit by hand, which matters for server infrastructure
• The [sni:hostname] section convention is a clean way to handle per-host TLS config without needing nested structures

Tradeoffs accepted:

• No native support for lists (they work around this with comma-separated strings, e.g. parse_value for Array(String) splits on ,)
• No nested structures, but the config doesn't need them
• No typed values — everything is a string that gets parsed, but the annotation-driven macro system (IniOpt, CliOpt, EnvOpt) handles type coercion cleanly

Compared to alternatives:

• YAML/TOML would add complexity and dependencies for features they don't need
• TOML would be the closest "upgrade" if they ever needed richer types, but there's no sign they do
• Environment variable and CLI overrides layer on cleanly since INI values are simple scalars

In short — it's the right level of complexity for the problem. No reason to reach for something heavier.

❯ Is there standard for the INI format?

● Not really — INI has no single authoritative standard. It's a de facto format with many dialects. Different implementations disagree on things like:

• Comment characters (# vs ; vs both)
• Quoting rules for values
• Whether duplicate keys are allowed
• Whether nesting/subsections exist (e.g. [section.subsection])
• Case sensitivity of keys and sections
• Multi-line values
• Escape sequences

The closest thing to a formalization is the Wikipedia page, which documents common conventions. Some implementations have their own specs (Python's configparser, systemd's unit file format, etc.) but they all differ in edge cases.

Crystal's INI module implements a basic subset — no quoting, # and ; for comments, = delimiter, flat sections. It's fine for LavinMQ's needs but it's worth being aware that there's no spec guaranteeing interoperability if you ever need to parse the same file with a different tool.

[carlhoerberg]

Is there a well maintained TOML parser for Crystal? Otherwise i think it's a no. stdlib implementation is a big pro for INI. I can't think any other app in another language with a incompatible INI parser what would need to parse the LavinMQ config.

[dentarg]

I guess this does not qualify as well-maintained as it does not seem to support the last two TOML versions (v1.0.0, v1.1.0), but I'll link it for the record: https://github.com/crystal-community/toml.cr