[gtkada] configuration files

[Stephen Leake]

Preben Randhol <randhol at pvv.org> writes:

> Stephen Leake <stephen_leake at acm.org> wrote on 29/05/2002 (14:16) :
> > Preben Randhol <randhol at pvv.org> writes:
> >
> >
> > Yes, but if I have two distinct databases, both accessed by 'myadadb',
> > then I need two distinct config files. I can use /etc/myadadb/.myadadb
> > and ~/.myadadb as defaults, but I also need a way to specify any
> > arbitrary name (perhaps as a command line parameter).
> 
> Ah nonono then you do it like this:

<snip multi-file structure>

Of course that works. So does specifying the file on the command line
:).

The point would be to let the ini package support all of these paradigms.

> > Well, there are other possible formats that are platform independent.
> > For example, X windows stores stuff like this in a similar format; I
> > have not looked at it in detail.
> 
> Section "ServerLayout"
>         Identifier     "Default Layout"
>         Screen         "Default Screen" 0 0
>         InputDevice    "Generic Keyboard"
>         InputDevice    "Configured Mouse"
>         InputDevice    "Generic Mouse"
> EndSection
> 
> Yes this is OK too. I meant that I want a text file that I can simply
> copy to Windows from Linux or visa versa and only have to change
> directory path in it to work on the other platform.

Yes. I would like to make sure we consider all the formats that are
already out there, before we pick one. No need to re-invent the wheel
here.


> > Because they are useful. I have written applications that stored
> > such data in files, so these routines are here. I like keeping
> > things strongly typed, so I want more than just String, Float,
> > Integer in config files.
> 
> I see, but can't we just make a
> 
>    generic
>       type Data_Type is private;
>    function Read
>       (File    : in File_Type;
>        Section : in String;
>        Keyword : in String;
>        Default : in Data_Type)
>        return Data_Type;
> 

This only works if you add a generic function parameter:

with function To_Data (Item : in String);

With my functions, the generic body uses 'Value. Not a big difference.

> But I really think it makes more sense to have all the Read
> functions simply done as Strings and then we make generic functions
> for converting the string to the type afterwards.

That's what I did, they are just in the same package, not "afterwords"
:).

> Another question should we expect the config file to be
> 
> keyword=value
> 
> in one line or can the value span several lines?

If it spans several lines, you need a value terminator character. Then
you need a quoting mechanism to include the line terminator in
strings. Not too hard, but I don't think it's worth it. If the parsing
gets too complex, we might as well just use XMLAda.

> Should we have
> 
> [Directory]
> 
> or
> 
> Section "Directory"
> EndSection

If we keep the one level section notion, I'd simply say we are using
Windows ini file syntax; then the files can be read by the Win32 API,
and we can read other Windows ini files. No loss for us.

-- 
-- Stephe