Re: [boost] Boost.Dynamic Config

Subject: Re: [boost] Boost.Dynamic Config
From: Dan Weber (dan_at_[hidden])
Date: 2011-02-14 20:18:41

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