Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Hal Finkel (half_at_[hidden])
Date: 2010-11-29 10:16:28

On Mon, 2010-11-29 at 15:27 +0300, Denis Shevchenko wrote:
> On 28.11.2010 05:24, Hal Finkel wrote:
> > I think a library for configuration-file parsing would be quite useful.
> > There are may use cases where an embedded scripting language is best,
> > but I think there are also many for which a dedicated
> > configuration-file-parsing library is superior.
> 
> Hello again, Hal!
> 
> One of the features of Configurator is semantics check. I understand 
> that semantics check is not a mandatory featureof such library, but I 
> check "standard values" only. IPv4, IPv6, email, path (in current 
> filesystem) - it is "global and immutable concepts". Imho, checking 
> these values at the time of parsing the configuration file is very useful.
> 
> Check the extended semantics ('time period' and 'size') was added 
> because I use it myself ('size' for max size of log file, and 'time 
> period' for different periodic thread tasks).Perhaps it will be useful 
> not only for me... :-)
> 
> What do you think about it?

Do you just mean a kind of parse-time validation framework (where the
parser checks that an e-mail setting looks like a valid e-mail address,
etc.)? That can be useful, but make sure that you can get warnings
instead of errors (for e-mail this is important). path checking is also
useful, but failure to exist is not always an error, sometimes the
application can create a missing directory, and complain only if it
cannot do so. In short, the behavior must be customizable.

On a different subject, the functionality that I think is missing from
configuration-file parsing libraries (generally, and I've looked at
quite a few) is a change-event-based interface to support runtime
reloading. It would be nice to be able to respond to "configuration
events" instead of iterating through a large tree structure. Then when
user requests the configuration be reloaded, the library only sends
change events for those things which have actually changed (this
requires matching named sections, since the order may have changed). I
should have the option of reusing the same event loop for initial
loading as well. I coded this for an application once, and it was a
pain, but worked well since the application "did what the user
expected", so I think it would be great to have this "configuration
diff" pattern encapsulated in a publicly-available library (it was a
server app, and it was important that connections logically unaffected
by a config change stay up, for example).

 -Hal

> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost