sysparam: split the key into a name-space and name. #638
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is largely to aid compatibility with other non-volatile stores that have limited sized names but support a name space. This might open a path to more compact storage of the key names although that is not implemented here.
Have been exploring how to also target code the esp-idf, and that requires a compatibility layer that works with the esp-idf nvs. The nvs has a default key names size of 15 characters, but supports name spaces so in total 30 characters. I found it convenient to keep longer key names in my app, so that the names are more obviously meaningful, and moving common prefixes to namespaces helped. For example all the wificfg keys are now in the 'wificfg' namespace, and the prefix has been removed from the name.
People might not like this PR, might argue that it was simpler the way it was. The use of the namespace is optional, it can be passed in as NULL, and existing names still read back.
One positive might be that it sets the stage for storing the name space names only once in the store, and referencing them by a shorter index. I did explore this, and made some progress, but decide it was not worth the added complexity.
If someone wanted to write a lighter weight 'nvs' for the esp8266 then that might just be adopted instead, but I am not holding my breath!