[gtkada] configuration files

[Jacob Sparre Andersen]

Preben Randhol wrote:

> Jacob Sparre Andersen <sparre at nbi.dk> wrote on 28/05/2002 (13:44) :
> > It looks reasonable execept for a few details:
> > 
> >  * I would like to have the option of reading the settings
> >    from a prioritised list of configuration files, and not
> >    just a single named file.
> 
> Do you want the pacakge to search through the files over
> and over again to find the value you want?

If the files are not read into a suitable data structure
which the values can be extracted from, yes.

> >  * The above mentioned prioritised list of configuration
> >    files should be initialised according to the conventions
> >    of the operating system used.
> 
> What do you mean by this?

If a parameter is set to some value in "$HOME/.bushrc", then
it shouldn't matter if it is also assigned a value in
"/etc/bushrc", which just works as system defaults in case
the users do not have any specific preferences. - In this
example the configuration file "$HOME/.bushrc" has a higher
priority than "/etc/bushrc".

> >  * It would be practical to include a function for reading
> >    the configuration file(s) into a suitable data structure,
> >    so the files only need to be read once during the
> >    execution of a program.
> 
> Why do we need to do it some complicated? This sounds
> like XML.

I was just thinking of a hash table for quick look up based
on section and parameter names.

> First settings files change from version to version of
> the program. So the first thing we need to do is to

If we decide to stick to the "ini file" format, then this
should not be a problem for the library, since it then by
definition will use a specific file format. The programmer
can always implement a version system if he considers it
important.

> The program will be writing and reading the settings
> files so the programmer knows the order in which the
> data comes.

If users are not supposed to edit the configuration files by
hand, then the format can just as well be a simple dump of
an internal data structure. The whole idea with using the
"ini file" format is that it is a known and somewhat
intuitive format for people to edit by hand. Introducing
specific limitations like parameter order will make it more
difficult for the users to edit the files, since they will
have to keep an eye on the parameter order as well.

Jacob
-- 
The great LEGO building competition of the year:
              http://www.1000steine.de/themen/bauwettbewerb/