[sword-devel] SWConfig Changes

[Troy A. Griffitts]

> - 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

I personally would like the constructor to take an SWConfig *, and the 
augment method to take SWConfig *

This way, if anyone decides to subclass SWConfig and make something 
silly, like SWRegistryConfig, they could still use your MultiConfig dealeo.


> - 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]

I think I prefer the [1] option.  Probably the LAST added SWConfig that 
contained the section.  What will probably happen, is that something 
like a systemwide module set will be loaded, then a 
~/.sword/userprefs.conf will be added to the config, which may override 
any entries in the systemwide file.  Actually, it would be cool to 
designate somehow that an SWConfig is readonly, or that an SWConfig is 
the default write, in case a section doesn't exist, it would be created 
in the default.




> - 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.

Actually, there is another ambiguous situation that the current augment 
code deals with.

consider:

file1.conf
[MHC]
GlobalOptionFilter=ThMLStrongs
GlobalOptionFilter=ThMLMorph

file2.conf
[MHC]
GlobalOptionFilter=ThMLFootnotes


In this case we want 3 entries in the final map

scenerio 2:

file1.conf
[MHC]
CipherKey=

file2.conf
[MHC]
CipherKey=ABCD1234EFGH5678IJKL

In this case we only want 1 entry.
Current code handles this the best it can guess.

> [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(),

As long as whatever you use is fast and portable, I'm game, BUT know 
that strtok is used all over the rest of the code, as well.


> 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 :)

great.  only add the using std::whatever you use.


> - make multimapwithdefault more efficient by caching iterators

Just be sure it's understandable fast and portable.


> - remove non-private member variables from the SWConfig

Please don't change the current interface.


> - modify the code to handle arbitrary line-lengths.
> 
> Any comments on these suggested changes are welcome.


I'm excited!  This functionality will be very coooool and useful!

	-Troy.

> 
> God Bless,
> 
> -David.