[sword-devel] SWConfig Changes

[David White]

Hi everyone,

I'm looking to get involved in Sword development, and Troy has asked me
to look at some changes to the SWConfig module. I have drawn up a brief
specification of proposed changes, and I ask interested parties to
peruse the specification and provide comments and feedback.

Current Behavior

- The SWConfig class will read in configuration information from a file,
the filename being given in the SWConfig constructor, and exhibit the
semantics of a map of maps, that is, a map of sections to maps of
name/value pairs.
- The SWConfig class has a Save method which will serialize the
information back to the configuration file
- Information from multiple SWConfig instances can be combined into one
using the += operator
- Limitation: although multiple SWConfig instances can be combined
easily, using +=, there is no way to serialize a modified SWConfig
instance to the files it was originally made up of.

Proposed Changed

- An additional constructor for SWConfig should be provided which takes
a sequence of configuration files, which are all loaded and combined
- A method should be provided which allows loading of a configuration
file and merging its contents with the current configuration information
- When the Save method is called, each section is serialized to the file
it originally came from
- If a section exists in multiple files, then only those names which
came from that file are serialized to the file.
- If a name/value pair has been added since the files were loaded, then
that name/value pair is serialized to all files which contain the
relevant section. [1]
- When loading multiple files, if different files have the same name but
different values, for the same section, then both name/value pairs will
be loaded. If they have the same name and the same value, then only one
of the copies will be loaded.

[1] an alternative scheme could see it only being serialized to one of
the files; perhaps the first file in the list, or an
implementation-chosen file.

I hope this makes sense :)

Some additional changes I might make:

- remove use of strtok(). strtok() is a non-reentrant function (not to
mention not thread safe), which is potentially dangerous, especially for
a library to use. Could be replaced by strtok_r(), or hand-coded parsing
(since the parsing is not complicated)
- get rid of using namespace std; in the header file. Just because
people want to use Sword doesn't necessarily mean they want 1000+
symbols imported into the global namespace :)
- make multimapwithdefault more efficient by caching iterators
- remove non-private member variables from the SWConfig
- modify the code to handle arbitrary line-lengths.

Any comments on these suggested changes are welcome.

God Bless,

-David.