Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-11-28 03:52:13

On 11/28/2010 07:38 AM, Robert Ramey wrote:
> or you could save a lot of trouble and just use the serialization library.
>    

If you are just referring to getting an application configuration stored 
and loaded by the same software, you may be right.  But given the OP 
list of features, are you sure you would save a lot of trouble?  I think 
there must be a number of those features that are not really supported 
well by serialization.  I assume you are referring to use an XML archive 
as it shall be simple to edit.  An XML schema could provide defaults, 
options, and validation rules, but  the serialization library does not 
dive that deep into the XML world, does it?  Sure, some of these things 
can probably be tweaked using custom validation code, and so forth, but 
what trouble is that saving.

Configuration files like the OP addresses is something that most often 
are hand-tweaked through simple tools like a text editor.  So in a sense 
it is a Human Machine Interface (HMI).  I am not opposed to using XML 
for program configurations, but I am concerned it is too big and complex 
of an of an hammer in most cases.  XML may make a lot of sense if the 
configurations require a lot of structure, support for extensibility, 
and you are addicted to the syntax.  Personally I am somewhat allergic 
to XML as HMI.  I think XML belong to the domain of machines talking to 
machines.  This is this the domain I also think serialization is 
designed for and not what I think the OP is addressing.

Configuration is really an activity when a system is instantiated, like 
when you install software on a host.  Configuration is used to override 
hard-coded source code values.  Some of these values are impossible to 
assume useful defaults for in source or detect during installation.  
Such values typically become required configuration values.   
Serialization typically comes to this game a step later when the 
deployed system is running.  Configured values can then again be 
overridden by system, user, or document preferences and made persistent 
through use of serialization.  If the same serialization code is used as 
part of an installer or configuration tool providing a good HMI, then 
serialization may be a good choice for storing the configuration.  So 
this all flows somewhat together in some cases while they remain very 
separate activities in other cases.

-- 
Bjørn