Evaluate JSON or TOML for operator-editable configuration
Workflow status is tracked in GitHub: https://github.com/emulebb/emulebb/issues/27. This local document is retained as an engineering spec/evidence record.
Summary¶
Evaluate whether selected text-editable eMuleBB configuration should move from legacy INI-style files to JSON or TOML while preserving profile portability, operator editability, and safe migration.
This does not approve a format switch by itself. The outcome should compare JSON, TOML, and the current INI approach for the configuration files that users or automation realistically edit by hand.
Candidate Areas¶
- Preferences that already have schema metadata and REST validation.
- Advanced/tweak settings that are hard to validate in free-form INI text.
- Test/live-run configuration where structured data would reduce ambiguity.
- New configuration files only, where no legacy compatibility surface exists.
Constraints¶
- Do not move binary
.metor.datpersistence under this item. - Keep existing profiles readable without destructive migration.
- Preserve comments or provide an equivalent operator-friendly strategy if the chosen format cannot round-trip comments.
- Define validation, defaults, unknown-key handling, and backup behavior before implementation.
Acceptance Criteria¶
- [ ] Compare JSON, TOML, and current INI behavior for hand editing, validation, comments, tooling, and Windows support.
- [ ] Identify which configuration files should stay unchanged.
- [ ] Define a migration and rollback strategy for any recommended format change.
- [ ] Define parser/library choices and failure handling.
- [ ] Produce an implementation plan with tests before any format change lands.