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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk