[gtkada] configuration files

[Ebert, Rolf]

RE> I think we should split the discussion into two areas:
RE> 
RE> A) functionality that has to be provided to clients of the package B)
RE> file (database) format of the actual configuration file
RE> 
RE> Defining the functionality (A) leads to the design of a specification
RE> file.
RE> 
RE> Defining the file format (B) defines the requirements for the
RE> implementation of the body.
RE> 
RE> Some of the requirements for A:
RE> 
RE> A.1: The underlying file format shall not be implied by the spec file

PR> That is ok.

RE> A.2: A hierarchy of keys shall be possible Note: The top level
RE> hierarchy is usually called section by now.

PR> Please give an example

Property files:
dirsync.gui.show_ignored=true
   ^     ^       ^         ^
   |     |       |         +--  value
   |     |       +------------  key
   |     +--------------------  subsection
   +--------------------------  section

Windows .ini files (no nested section available):
[gui]               <---------  section
show_ignored=true   <---------  key and value

XFree86 style files:
Section "Screen"    <---------  section
   SubSection "Display"  <----  subsection
       Depth  4
         ^    ^
         |    +---------------  value
         +--------------------  key


RE> A.3: Multiple levels of hierarchy are preferable (I do not think that
RE> there is consensus on this one)

PR> You mean sections inside sections? Is this needed?

Yes, I think they are neat and they match well the nested hierarchies of Ada
packages

RE> A.4: All values shall be accessible as strings at least
PR> Yes, Strings.

RE> A.5: A list of keys available in a given section shall be retrievable
PR> Yes.


RE> I do not like the idea to write values back to a configuration file.
RE> I would place the writing routines in  child package or leave them out
RE> completely.

PR> You mean that one should only be able to read config files? I would like
PR> to use the package to write the config files too. Then I know that the
PR> config file gets correct.

Yes, so far I had almost never had the need to write values to a
configuration file from within a program.  I usually use Emacs for that :-)

PR> What about that the package reads only one section at a time? Of course
PR> this can be a problem if it is allowed to have an arbitrary order of the
PR> sections.

A.6: value retrieval shall not depend on the order of sections or keys
within the configuration file

OK, then what about users putting the same key twice in a config file.  Do
we stop reading after having found the first one, or do we completely read
the file and the last one (silently) overwrites the previous occurences?

 
RE> Notes on B:

RE> I think we can write multiple bodies for the different file formats.
RE> I can even imagine a heursitic that at least the reading routines
RE> detect the file format automatically.

PR> Why? It leads only to confussion on the syntax of a programs config file
PR> It would be nice if all Ada program have the same config file format.
PR> Besides at least I would like the package as small as simple as
PR> possible.

Agreed, having the same file format everywhere is desirable.


PR> I would though prefer:

PR> Section "Screen"
PR>    Identifier  =  "Default Screen"
PR>    Device      =  "Generic Video Card"
PR>    Monitor     =  "Generic Monitor"
PR> 
PR> etc...
PR> 
PR> to distinguish keyword and value better.

Agreed, but I'd put the equal sign and the quotes to be optional.  The
reading routines should accept the file with or without them.
 
RE> As an aside: has anybody looked at the file format for the gnat
RE> project files as of gcc-3.1.  This is almost pure Ada!

PR> No, can you show an example here?

project Debug is
  for Object_Dir use "debug";
  for Main use ("proc");

  package Builder is
    for Default_Switches ("Ada") use ("-g");
  end Builder;

  package Compiler is
    for Default_Switches ("Ada")
       use ("-fstack-check", "-gnata", "-gnato", "-gnatE");
  end Compiler;
end Debug;

See the file gnat_ug.texi in the ada subdirectory of the gcc-3.1 sources for
an explanation of the file format.

	Rolf Ebert