Re: [boost] Boost.Dynamic Config

Subject: Re: [boost] Boost.Dynamic Config
From: Dan Weber (dan_at_[hidden])
Date: 2011-02-14 12:36:47

Hi Mathias,

I've found that property_tree and program_options are deficient in
solving this problem.

For instance, property_tree requires full serialization back and forth
for each time you write to the underlying data store, so it could not
guarantee that it has the most accurate data all the time.

As for program_options, it only works one way that is for reading
options.  It is also not thread safe.

The goal of this is keep live runtime configuration that can be globally
modified, both in the application and outside of it while making it easy
to support new backends.

I've started the initial implementation starting with the registry, and
it can be found here:

https://github.com/omnisip/boost.dynamic_config
git://github.com/omnisip/boost.dynamic_config.git

There are several things I'm already aware of what I want to change.
For instance, to support backend specific configuration, I want to
switch the constructor of basic_property_config to take an argument of
backend::configuration_type const &.  For backends that support or
require those configurations, they can be passed to the constructor,
with a default being backend::configuration_type().  So in the event of
a simple backend, you could possibly have a backend::configuration_type
of none_t.  While others like the registry could have custom parameters
regarding how it handles HKCU/HKLM or both as well as the organization
name and application name components.

Additionally, I think backends could be simpler to implement using a
facade of sorts that the backend implementation inherits from with a
template parameter of itself.  This would make it so that the bare bones
backend would only need to support things like std::string/std::wstring
or string_type as I have it typedef'd.

This is beneficial because it simplifies implementation of any sort of
file backend at a bare minimum.  I've used an approach that takes
boost::lexical_cast<> for all non-native types of the backend and
converts them to strings in the windows registry backend.

There are also some other nifty features of that backend that I've been
working on.  For instance, the windows registry supports only a couple
of integer types, DWORD and QWORD which are uint32_t and uint64_t
respectively.

The backend implementation takes this into account for any Integral
types that come in using std::numeric_limits<Integral>::digits to make a
distinction as to how to store it in the registry with the right amount
of precision necessary.

I know I also need to add some sort of support for iteration of subkeys
and iteration of values, but I haven't quite come up with the method I
want to use to do that yet.  Likewise, I would need to standardize on a
notation for searching through subkeys and so forth, e.g. 'dot notation'
or '/' notation..

Dan

On 02/13/2011 03:44 AM, Mathias Gaunard wrote:
> On 12/02/2011 18:51, Dan Weber wrote:
>>
>> Hi guys,
>>
>> I feel as part of the Boost community and having worked on multiple
>> platforms that we're missing something to manage reading/writing
>> configuration information for an application thread safely across
>> platforms.  The best example I know of that handles this job is Qt's
>> QSettings which writes to the registry on windows, inis on linux, and
>> some
>> sort of xml on Mac OS X.
> 
> What about property_tree and program_options?
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost