Currently lib is supporting only search and validate functionality. Is it planned to support “modify” action in future?
Hi. We’d like to hear about your use case. Right now, we’re contemplating a compose API to create a new JSON document, but that would not extend to modifying the JSON in an existing buffer. To keep memory usage small, both validate and search functions parse the buffer directly, without creating an external syntax tree. This tradeoff limits how we might approach making changes to an existing JSON document.
Hi,
I’m considering to use JSON to keep my device settings. It is running under freeRtos. We plan to add flash file system and configuration files and JSON is one of candidates as file format.
But I need to have possibility to modify existing configuration and even creation of JSON by device.
The main issue I want to solve is situation when with new release of my firmware the new setting is added to existing settings e.g.:
Firmware version 1:
{
“setting1” : value
}
Firmware version 2:
{
“setting1” : value
“newSetting” : value
}
Story:
Device is sing firmware 1, after loading firmware 2 to device the “newSetting” is not existing so device has to add it.
Moreover setting1 can be set/change by unit during running firmware 1 so we want to keep it with no changes after loading firmware 2
Thanks for sharing your use case. In my experience, JSON is often used to serialize a binary structure. Such a structure can be written directly to non-volatile storage, but it is also trivial to convert to JSON first with a function like snprintf().
#include <stdio.h>
struct config {
int setting1;
int newSetting;
};
int makeJSON( char * buffer, size_t max, struct config * config )
{
return snprintf( buffer, max, "{\"setting1\":%d, \"newSetting\":%d}",
config->setting1, config->newSetting );
}
Having such a function avoids the need to modify an existing JSON document.
As a best practice, adding a version number to your configuration makes it possible to tackle any significant schema changes. For simple changes like adding newSetting, the firmware #2 can provide a default when initializing the structure, while the function that reads the JSON from NVS iterates over a known set of keys, only updating the struct when a key is present. The makeJSON() function can then be used to save the new key to NVS.
Have you considered using an off-device configuration store (e.g., AWS IoT Device Shadow)? It also addresses this use case.