WDYT of using key-value encoding rather than INI encoding?

[vlsi]

I believe a structured encoding for key-value might be easier to parse.

For instance:

unit16_t keySize;
char* key;
uint16_t valueSize;
char* value;

The specification might add a limit like 128 bytes for the maximum key and value, so the consumers can reject files if a key or value exceeds 128.

[bubnikv]

I don't think it makes much difference, however an ini format has the benefit of being human readable in a text editor, even though it is embedded inside a binary format.

čt 26. 10. 2023 v 14:18 odesílatel Vladimir Sitnikov < @.***> napsal:

I believe a structured encoding for key-value might be easier to parse.

For instance:

unit16_t keySize; char* key; uint16_t valueSize; char* value;

The specification might add a limit like 128 bytes for the maximum key and value, so the consumers can reject files if a key or value exceeds 128.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/libbgcode/issues/27, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI5MVDUNF4CL7DS2NITYBJIKVAVCNFSM6AAAAAA6RDOGQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3DGNBTGY3DQMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[vlsi]

char* key and char* value would be visible as well. However, they will be much easier to generate and parse. For instance, binary encoding would not need escape processing which is inevitably needed for INI.