| id | REF-046 | ||||||
|---|---|---|---|---|---|---|---|
| workflow | github | ||||||
| github_issue | emulebb/emulebb#27 | ||||||
| title | Evaluate JSON or TOML for operator-editable configuration | ||||||
| status | OPEN | ||||||
| priority | Minor | ||||||
| category | refactor | ||||||
| labels |
|
||||||
| milestone | post-0.7.3 | ||||||
| created | 2026-05-24 | ||||||
| source | user-requested future backlog item for editable configuration formats |
Workflow status is tracked in GitHub: emulebb/emulebb#27. This local document is retained as an engineering spec/evidence record.
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.
- 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.
- 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.
- 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.