Hi Rob, [notes inlined below]
The idea is interesting, but there are a great many features such a mechanism could include beyond those you've mentioned, though they may not work so well for the various backends.
There are certainly many possible features, however, I want to keep this as simple to implement as far as new backends.
For example, when processing configuration files, you could support include directives or conditional processing. You could support reusable values; IOW, permit reusing a given value in defining the value of various other entries.
I think it should be noted that I am not particularly interested in targeting configuration files. I'd rather support something along the lines of sqlite databases than flat files since the goal is to make this primarily for the most up to date runtime configuration/program options.
What about the ability to filter which entries apply? In, again, a configuration file, there could be key elements that identify the application or instance to which they apply. Then, based upon runtime values, entries with those extra key parts would be filtered if they don't match. (Another approach is to require wildcards so all keys have the same structure.)
There are various configuration formats that support data structures like dictionaries, lists, etc. These are highly useful for capturing come configuration information. Without direct support, one must create ad hoc string formats that must be parsed by each application requiring them.
Why do you want to update the configuration store at runtime? What are the use cases for that behavior? When I think of configuration files, I think of /etc. You almost never see an application update it's own configuration file at runtime. The goal of runtime configuration is to store user specific settings that otherwise could not be easily stored. For instance, in one of my applications, I'd like to store the position of the volume control, the default layout of the window, and so forth.
What do you mean by thread safety? Do you anticipate much MT demand for updating configuration information that the application couldn't just synchronize updates rather than embedding that behavior in the configuration class(es)?
The value in this for me is a volatile online database. Previously, I have used things like TBB's concurrent_hash_map in a static context to keep data available for all threads to reach and update while the application is running, but this provides no native persistence mechanisms. However, consider the Windows Registry or GConf. These systems can serve the role of quickly retrieving configuration values and dynamically storing new ones while still persisting to disk at some point. Likewise, these backends are natively thread safe. In addition to those, making it easy to add new backends, also makes applications more portable. Interestingly enough, sqlite has become incredibly important for configuration on things like phones because it provides the capabilities I need from my applications that run on desktops and servers. It can fully meet the criteria to operate as a backend. After several people have said this, I will also focus on some name changes that seem suitable. Thanks, Dan