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