Re: config files proposal

[Stephen Leake <stephen_leake@acm.org>]

antonio_duran@hotmail.com (Antonio Duran) writes:

> 1. In my experience, most of the time, config files are writen, edited
> or modified by humans and read and interpreted by programs. With this
> in mind, in my modest opinion, the importance of having an API for
> writing to config files is secondary. What is important is having the
> means that allow a human user to understand what is in the config
> file.

True.

> Configuration tasks are simpler if the config file is commented and
> handling comments is difficult if you use an API call to write to
> the file. 

Good point; I hadn't thought of that.

I think this makes XML a better idea; we can allow for a "comment" tag
that is saved in the memory image, and written back out.

> When config file gets complicated enough one must write an
> application to handle it (eg. Comanche to mantain Apache config
> files).

Yes. We need to support both modes of operation.

> 2. Seems that there is a consensus in that a config file must store
> key/value(s) pairs. I don't understand the requirement to use
> Wide_String for keys. I'm from Spain and I usually write in Spanish
> but when programming in Ada I must adhere to the Ada syntax, I can't
> write Ada identifiers that are syntactically correct spanish words
> and the Ada reserved words are english words. 

Yes, but there's no reason config files have to have the same
restrictions. 

> Supporting Wide_String could be a cool feature for, for example,
> mantaining localized messages in different languages, however: is
> this the purpose of config files?. 

You could use them that way. In this particular case, the Gnu
'get_text' facility is probably better. But if you have only a few
messages, and also other things to configure, a config file would be a
good place to do this.

> I think the purpose of config files is to provide parameters to a
> program or application and not to be used as a repository for
> localized versions of program messages. Of course, they could be
> used in that way. I suggest that keys in config file meet the Ada
> syntax for identifier and be case-insensitive.

Ok, thanks for your input. 

But, I'd like you to think again :). Can you come up with any
situation in which you would use Wide_String keys? Do you use
Wide_String for anything in your applications?

Here in the US, it's easy to think "ASCII solves all problems"; I'd
appreciate some input from someone for whom that is not true.

> 3. I think that is important to handle more than one config file in
> a single program. From my point of view, one of the most important
> drawbacks of layouts such as the Windows Registry is that everything
> is on a single place so applications that can access to a single
> part can also write other parts. In complicated apps it could be
> desirable to mantain a set of different config files one for each
> part of the application. The ability for handling multiple config
> files in a single program should be a requirement for a config file
> handling package.

Yes, I intend to support this. Please check the draft spec when I post
it, to see if it meets these needs.

> 4. I don't understand very well the implications of "... specified
> by generic parameter at compile time ..." (API req. 5). Does this
> mean that the name or the path of the file must be hard coded?. 

only the defaults; API req 7 allows the application to override these
defaults. 

> If so I think we've missed totally the point (should I recompile
> each time I change the name or location of the config file?).

The point was that some applications (typically from Gnu and/or Linux)
put config files in very standard places, like /usr/local/share. So
this default should be compiled in on Linux. However, other
applications will want to specify thier own places for config files,
so that has to be allowed as well.

> 5. Regarding to the file syntax, long time ago I worked on a system
> that runs on CAIS (Common APSE Interface Set). 

> <snip example>

> There are, however, some drawbacks in this representation:
> 
> - A escaping schema is needed for unprintable characters in strings
> (?).
> - Nested '(' and ')' would add a high degree of complexity for the
> human user/reader.

And it's really only readable for people who know Ada; we'd like this
to be useful to a wider audience.

-- 
-- Stephe