ideas for future of the settings

[nvlsianpu]

Objective for this Issue is to collect ideas and requirements for future improvement of the settings.

Background:

The settings subsystem aimed to persistent storage of run-time settings for zephyr modules and applications. It is supposed to provide same API over any low-level storage system it uses.

Current high level architecture:

Settings subsystem is based on what was ported and reworked for MyNewt configuration subsystem. Settings subsystem push settings to the zephyr modules - any client of the settings needs to provide handlers for serve injection on its data, and handlers for serve storing request of its data.

Conclusion on usage:

Looks like the settings needs lot of improvements. some of them are in progress. Some of advance developers states that in long time horyzont (~2 years) it should be totally replaced by something better designed and better fit to our purposes.

This issue should be used to collect all ideas for improvements - some of them may be doable for current settings, some might not. Based on what will be collected decisions on next steps will be made.

Discussion is started as the result of conclusion from dev-meeting, which took place 06.06.2019 and was touching move forward for PR: #16609.

[nvlsianpu]

@padu @rakons @Laczen @carlescufi @jhedberg @Vudentz @fnde-ot @aescolar

[jhedberg]

Is this a duplicate of #16676?

[carlescufi]

Is this a duplicate of #16676?

I think it's the other way around, since this one was created first. @Laczen can we move the contents of your issue here and track this in a single issue?

[Laczen]

@carlescufi, of course you can. But maybe this issue is more ambitious than mine and can be held as a placeholder for where zephyr would like to end. If wanted I can write some things about what the advantages are of doing it as done, so that we do not loose these as new idea's are proposed.