[gtkada] configuration files

[Stephen Leake]

"Ebert, Rolf" <rolf.ebert at bms.de> writes:

> I think we should split the discussion into two areas:
> 
> A) functionality that has to be provided to clients of the package
> B) file (database) format of the actual configuration file

These are separate, but it's really not that complicated :).

> Defining the functionality (A) leads to the design of a
> specification file.

By "specification file" you mean "Ada package specification"? That
is, the Ada API?

> Defining the file format (B) defines the requirements for the
> implementation of the body.

Yes.

> Some of the requirements for A:
> 
> A.1: The underlying file format shall not be implied by the spec
> file

Yes.

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

Yes, I like this better than only one level.

> A.3: Multiple levels of hierarchy are preferable (I do not think
> that there is consensus on this one)
> 
> A.4: All values shall be accessible as strings at least

Hmm. I guess there's nothing to prevent that. I'm not clear why you
would want to retrieve a number as a string, but I guess you can. To
skip to B; normally I would require quotes around strings in an "ini"
file, but I guess if there are no quotes then whitespace delimited
works.

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

Yes. I guess this is complicated if their is more than one level in
the hierarchy. This list should only give the next level in the
hierarchy, not the full subtree. Or at least have a switch to allow
the user to control that.

> A.6: others...

A.6 Provide both read and write

A.7 Allow specifying a search path, and a list of default file names.

A.8 Provide generics to allow the user to read and write numeric
types.

A.9 Do _not_ provide support for non-scalar types other than strings.

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

Why? One thing I want to store in a config file is the window
placement and size. The user sets this by dragging with the mouse; the
program writes it to the config file. I certainly don't want to make
the user figure out what numbers to type in the config file to do this.

Putting them in a child package is certainly possible, but I think it
is unnecessary. If you don't want to write, don't use the write
functions.

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

Well, I guess that's possible, but again, more complex than necessary.

> I like the idea of the
> 
>    Section "Directory"
>    EndSection
> 
> format.  This looks quite similar to Ada itself.  Is it possible to have
> nested sections.  How do they look like? 

Yes, the exact syntax of hierarchical levels is not clear.

I think

level_1.level_2.level_3.key = value

is good enough, but I haven't tried to implement it yet, so I'm not sure.

> As an aside: has anybody looked at the file format for the gnat
> project files as of gcc-3.1. This is almost pure Ada!

That's an excellent idea! There's even open source code for reading
and writing it! Darn, I wish I'd thought of that :). I'll have to see
if I can find the source for this; I haven't unzipped the GNAT sources
on this machine yet.

-- 
-- Stephe