Problem
Currently configuration is stored as binary blob that is read using offsets.
This creates problems when a fork/update introduces/changes a new config setting.
Solution
Using a proper serialization method could keep the config more flexible and future proof.
E.g. forks could introduce new config options and users could keep their config and just flash other software.
I'd suggest CBOR but JSON would also be a good choice.
Since CBOR and JSON can be "valid" a fallback could be implemented (check if config file is valid CBOR first, if not fall back to BLOB)
There are multiple libraries for embedded computers to handle both formats.
Problem
Currently configuration is stored as binary blob that is read using offsets.
This creates problems when a fork/update introduces/changes a new config setting.
Solution
Using a proper serialization method could keep the config more flexible and future proof.
E.g. forks could introduce new config options and users could keep their config and just flash other software.
I'd suggest CBOR but JSON would also be a good choice.
Since CBOR and JSON can be "valid" a fallback could be implemented (check if config file is valid CBOR first, if not fall back to BLOB)
There are multiple libraries for embedded computers to handle both formats.