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