config files proposal

config files proposal

[Stephen Leake]

I've posted a summary of the requirements and options for a config
file standard, at
http://users.erols.com/leakstan/Stephe/Ada/config_files.html 

I'm going to experiment with an XML implementation before I post a
draft spec; I suspect using XML for the file format will have an
impact on the spec. If I find XML too complex, I'm leaning towards the
Java property style.

Please comment on the requirements. 

Please don't say "just use the registry"; let's take that discussion
as settled :). The consensus is we need both the registry and a
simpler config file.

I'm on vacation starting Tuesday (back the following Monday), so I
won't be responding to comments till then. I'll try to catch up on all
of this thread when I get back, but feel free to send me email
directly at stephen_leake@acm.org.

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> http://users.erols.com/leakstan/Stephe/Ada/config_files.html

I would suggest using Wide_String for keys. (API#8)

You need to specify where a file is written in the path. (API#6) apparently
only talks about reading files.

FF #1 has to deal with the differences between systems anyway. Character
sets, newlines, etc. Or at least mention what you mean.  That is, file
format #1 kind of conflicts with file format #2, if Text_IO writing on one
system isn't readable on another.

FF #3 I would disagree with. It limits having large items in the config file
format. Making key/value pairs terminated by a newline is specifying the
implementation. It doesn't make any sense to do such a thing in XML, for
example. Perhaps starting continuation lines with a space as is done in RFC
822 headers would make more sense. In addition, API#15 conflicts with this
requirement.

FF#4 should be written as "leading and trailing whitespace on keys and
values is semantically meaningless". 

Question: Are keys case-sensitive?

Question: What about where most of the configuration is stored in a
system-wide file, with individual users capable of overriding particular
entries?  Kind of like /etc/bashrc and ~/.bashrc on Linux?

Question: Does the file automatically flush changes as it goes out of scope?
(API#4)

Question: Is the file closed (w.r.t. the OS) between the end of the read and
the start of the write?

Question: Would it make sense to allow compound values to be written by
converting a stream of them to base64 or something?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Darren New]

Darren New wrote:
> FF#4 should be written as "leading and trailing whitespace on keys and
> values is semantically meaningless".

Oh, and then you have to specify the quoting rules for values where leading
and/or trailing whitespace *is* significant.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > http://users.erols.com/leakstan/Stephe/Ada/config_files.html
> 
> I would suggest using Wide_String for keys. (API#8)

Hmm. Good idea. I'm not clear why I limited that. But I'm glad I made
it specific, so you could point out it was wrong :).

> You need to specify where a file is written in the path. (API#6)
> apparently only talks about reading files.

It should be written where it is found; I'll add that. Hmm, special
case if it is a new file; write it to the first directory in the
search path.

> FF #1 has to deal with the differences between systems anyway.
> Character sets, newlines, etc. Or at least mention what you mean.
> That is, file format #1 kind of conflicts with file format #2, if
> Text_IO writing on one system isn't readable on another.

Good point. I guess I need to say "files can be copied with normal
system-dependent changes (such as line endings)."

> FF #3 I would disagree with. It limits having large items in the
> config file format. 

Only if there is a maximum line length. I guess some text editors
might impose one, but Ada.Text_IO doesn't.

> Making key/value pairs terminated by a newline is specifying the
> implementation. 

Yes, but that's what FF is about anyway.

> It doesn't make any sense to do such a thing in XML, for example.

True.

> Perhaps starting continuation lines with a space as is done in RFC
> 822 headers would make more sense. 

Well, I guess there are many ways to deal with mult-line formats.

> In addition, API#15 conflicts with this requirement.

I don't see how. API#15 says "the client may provide a string image of
a composite type". How does that imply multiline values. Ah; the
client could embed a newline in the string. Guess I should forbid
that.

But I'm leaning towards eliminating API#15 anyway; given multi-level
sections, I realized there's no need for it. I had it in my Windows
ini package, because there is only one level of sections.

> FF#4 should be written as "leading and trailing whitespace on keys
> and values is semantically meaningless".

Yes, much better. Thanks.

> Question: Are keys case-sensitive?

Good point. I think I'll go with the Ada identifier model and say
"no". 


> Question: What about where most of the configuration is stored in a
> system-wide file, with individual users capable of overriding
> particular entries? Kind of like /etc/bashrc and ~/.bashrc on Linux?

I'm not sure what your question is. Oh, I see; you want me to request
key "foo", and if not found in ~/.bashrc then look in /etc/bashrc to
find "foo". Hmm.

I guess we could add an "append_read_only" operation, that would read
in a second file, and store it in a separate read-only tree. I like
that. 

> Question: Does the file automatically flush changes as it goes out
> of scope? (API#4)

Yes, I need to add that. Guess that makes it Controlled; I think it
would be anyway, to avoid memory leaks.

> Question: Is the file closed (w.r.t. the OS) between the end of the
> read and the start of the write?

Yes. Actually, I think the file is OS closed at the end of Open, after
the data is read in.

I'm planning on renaming the file to a backup name before writing it,
for glitch protection.

> Question: Would it make sense to allow compound values to be written
> by converting a stream of them to base64 or something?

I think composite values are best handled by multiple levels. Ie, if
you have a record:

type Foo is record
   a : integer;
   b : integer;
end record;

you write this as (assuming Java property style)

foo.a = 1
foo.b = 2

base64 would be good for values that don't need to be user editable. I
guess persistent storage for a large object (whether it is composite
or not) could be supported that way. I'm not clear why that would be
in a typical "config file". Hmm, maybe a pixel bitmap for an icon?

Thanks for your comments!

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> > You need to specify where a file is written in the path. (API#6)
> > apparently only talks about reading files.
> 
> It should be written where it is found; I'll add that. Hmm, special
> case if it is a new file; write it to the first directory in the
> search path.

The problem here is if you load a system-wide config file, make changes, and
want to save it. You at least need a routine that says "pretend you got it
from *here*" or something; i.e., to change the name&path of the file between
reading and writing.
 
> > FF #3 I would disagree with. It limits having large items in the
> > config file format.
> 
> Only if there is a maximum line length. I guess some text editors
> might impose one, but Ada.Text_IO doesn't.

Hrm. Perhaps.
 
> > In addition, API#15 conflicts with this requirement.
> 
> I don't see how. API#15 says "the client may provide a string image of
> a composite type". How does that imply multiline values. Ah; the
> client could embed a newline in the string. Guess I should forbid
> that.

Right. Actually, I read it as "provides a way to read/write the value". I
hadn't read it as "... as a String value" but I guess someone more atuned to
Ada would read it that way.

> But I'm leaning towards eliminating API#15 anyway; given multi-level
> sections, I realized there's no need for it. I had it in my Windows
> ini package, because there is only one level of sections.

I think it depends on just how you build the API.

> > Question: Are keys case-sensitive?
> 
> Good point. I think I'll go with the Ada identifier model and say
> "no".

If "no" and you're allowing Unicode, then you have to worry about the
bizarre transformations that some languages have.
 
> I guess we could add an "append_read_only" operation, that would read
> in a second file, and store it in a separate read-only tree. I like
> that.

That's how I've always done it. That also solves the problem of "where do I
store changes if there was no file found when I read?"
 
> I'm planning on renaming the file to a backup name before writing it,
> for glitch protection.

Make that optional. Or write to a new file, and rename over the old one.
Some OSes may do this for you automatically. Other OSes supply specific
routines to do this properly (maintaining file attributes and ACLs, etc.)
 
> base64 would be good for values that don't need to be user editable. I
> guess persistent storage for a large object (whether it is composite
> or not) could be supported that way. I'm not clear why that would be
> in a typical "config file". Hmm, maybe a pixel bitmap for an icon?

That was actually my thought, yes. Funky how we both had the same example in
mind.
 
> Thanks for your comments!

Thanks for paying attention! :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > > You need to specify where a file is written in the path. (API#6)
> > > apparently only talks about reading files.
> > 
> > It should be written where it is found; I'll add that. Hmm, special
> > case if it is a new file; write it to the first directory in the
> > search path.
> 
> The problem here is if you load a system-wide config file, make changes, and
> want to save it. You at least need a routine that says "pretend you got it
> from *here*" or something; i.e., to change the name&path of the file between
> reading and writing.

Good point. I guess I can check the write privs on the found file. 

Or provide two search paths; one read-only and one writeable.

> > > Question: Are keys case-sensitive?
> > 
> > Good point. I think I'll go with the Ada identifier model and say
> > "no".
> 
> If "no" and you're allowing Unicode, then you have to worry about the
> bizarre transformations that some languages have.

yes. And Glib.XML is case sensitive. Although Glib.XML also uses
String for Tags, not Wide_String. So I have to check the XML
definition; does it allow Wide_String for tags? Hmm.
http://www.w3.org/TR/2000/REC-xml-20001006#NT-Letter seems to imply 16
bit characters, but I'm not clear on whether it's UniCode or something
else. There's also the issue of what Wide_Text_IO actually writes.

> > base64 would be good for values that don't need to be user editable. I
> > guess persistent storage for a large object (whether it is composite
> > or not) could be supported that way. I'm not clear why that would be
> > in a typical "config file". Hmm, maybe a pixel bitmap for an icon?
> 
> That was actually my thought, yes. Funky how we both had the same example in
> mind.

Yes. However, a better solution for bitmaps is to keep the bitmap in a
file that a bitmap editor will recognize, and put the path to it
(possibly relative) in the config file. 

But we don't need to _forbid_ binary data in the config file, if it's
not hard to do.

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> Good point. I guess I can check the write privs on the found file.

Naw. 
 
> Or provide two search paths; one read-only and one writeable.

Or just require the full path to the config to be saved, and perhaps default
it to where it was loaded from. I think if you try to "guess" which config
file to clobber, you're going to guess wrong too often.
 
> > If "no" and you're allowing Unicode, then you have to worry about the
> > bizarre transformations that some languages have.
> 
> yes. And Glib.XML is case sensitive. Although Glib.XML also uses
> String for Tags, not Wide_String. So I have to check the XML
> definition; does it allow Wide_String for tags? Hmm.

XML is case sensitive and uses unicode.

> http://www.w3.org/TR/2000/REC-xml-20001006#NT-Letter seems to imply 16
> bit characters, but I'm not clear on whether it's UniCode or something
> else. 

UTF-8 or UTF-16, as far as I understand.

> There's also the issue of what Wide_Text_IO actually writes.

That too.

> Yes. However, a better solution for bitmaps is to keep the bitmap in a
> file that a bitmap editor will recognize, and put the path to it
> (possibly relative) in the config file.

Possibly. Depends on what you're trying to accomplish.
 
> But we don't need to _forbid_ binary data in the config file, if it's
> not hard to do.

Correct. But if you want it editable, you probably need to keep it text.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > Good point. I guess I can check the write privs on the found file.
> 
> Naw. 

Hmm. What if I find a "system" config file, that I _don't_ have write
priviledge for?

> > Or provide two search paths; one read-only and one writeable.
> 
> Or just require the full path to the config to be saved, and perhaps default
> it to where it was loaded from. I think if you try to "guess" which config
> file to clobber, you're going to guess wrong too often.

With clear rules about it, there's no "guessing". Here's my proposed
rule:

---
There are two search paths; one for files that are read only, one for
files that are writeable.

If the first config file is found on a read only path, the "flush"
operation creates a new file in the first directory of the writeable
path.
---

That gives total control to the client of the Config_Files package.

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > Stephen Leake wrote:
> > > Good point. I guess I can check the write privs on the found file.
> >
> > Naw.
> 
> Hmm. What if I find a "system" config file, that I _don't_ have write
> priviledge for?

Sorry. I forgot to finish that sentence. I meant  "Naw, that's not good
enough." Or would you want root changing the system configuration every time
she ran your program?

> > > Or provide two search paths; one read-only and one writeable.
> >
> > Or just require the full path to the config to be saved, and perhaps default
> > it to where it was loaded from. I think if you try to "guess" which config
> > file to clobber, you're going to guess wrong too often.
> 
> With clear rules about it, there's no "guessing". Here's my proposed
> rule:
> 
> ---
> There are two search paths; one for files that are read only, one for
> files that are writeable.
> 
> If the first config file is found on a read only path, the "flush"
> operation creates a new file in the first directory of the writeable
> path.
> ---
> 
> That gives total control to the client of the Config_Files package.

That would work, yes. That's a good compirimse. Especially if one can change
these paths at run-time, on a per-config-file basis. In that case, one could
simply change the writable path to a single directory to force a config file
to be written. I'd also suggest that it be legal to have a zero-length
writable path, leading to an exception if an attempt is made to write the
config file. (Or perhaps to have changes discarded?)

Altho I must admit I see no reason for a writable *path* as such. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Georg Bauhaus]

Darren New <dnew@san.rr.com> wrote:
: 
: UTF-8 or UTF-16, as far as I understand.

<?xml version='1.0' encoding='...'?>
declares "external representation". External entities in UTF-8/16 must
be read, others may. UTF-8 has the advantage of being stateless and
compatible across wires. We often have
<?xml version='1.0' encoding='ISO-8859-1'?>, useless for anything
outside "west-latin" tradition, but good and correct otherwise.

-- georg

Re: config files proposal

[Ted Dennison]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkznydwcm7.fsf@acm.org>...
> Darren New <dnew@san.rr.com> writes:
> > You need to specify where a file is written in the path. (API#6)
> > apparently only talks about reading files.
> 
> It should be written where it is found; I'll add that. Hmm, special
> case if it is a new file; write it to the first directory in the
> search path.

Perhaps I'm misunderstanding, but this sounds to me like you are
saying:

  1)  Users have very little control over where their config files get
written to.
  2)  There will be only one config file per system.
  3)  The facility will be dependent on the very system-dependant
feature of directory search paths.


I don't like the first two ideas at all, since they needlessly
restrict the funtionality. I could easily see loads of people who
would otherwise love to use the facility, forced to roll their own due
to problems with 1 and 2. Clients of the facility should be able to
read and write configurations to and from the directories and file
names of their choice.

The third issue I think requires a good deal of discussion before
being accepted. For one thing, it will prevent anyone from making a
portable implementation of the config file facility. It should also be
noted that if this facility's behavior depends on an
implementation-defined facility, then you are basicly saying that
(part of) this facility's behavior is implementation-defined. That in
turn means programs that use this facility are going to have
portability issues. In my mind, that's more serious than having
non-portable config files.

> > FF #3 I would disagree with. It limits having large items in the
> > config file format. 
> 
> Only if there is a maximum line length. I guess some text editors
> might impose one, but Ada.Text_IO doesn't.

Since it requires that the user supply a fixed-length buffer,
Ada.Text_IO effectively *does* impose a limit. It just lets you decide
what that limit is. :-)

> > Making key/value pairs terminated by a newline is specifying the
> > implementation. 

I'd disagree with this statement. It is (partially) specifying a file
format, but in no way specifies how the config file facility
implements it. The file format *has* to be part of the specification,
it can't be left as an "implementation detail".

Presumably this is just a first cut to get the "easy ones" ironed out,
before we start to agree on a file format. Right?

If so, a lot of this discussion will be rendered moot when the file
format is decided upon.

> > Question: Are keys case-sensitive?
> 
> Good point. I think I'll go with the Ada identifier model and say
> "no". 

I agree wholeheartedly, for the same reason.

> I'm not sure what your question is. Oh, I see; you want me to request
> key "foo", and if not found in ~/.bashrc then look in /etc/bashrc to
> find "foo". Hmm.
> 
> I guess we could add an "append_read_only" operation, that would read
> in a second file, and store it in a separate read-only tree. I like
> that. 

Perhaps it would be better to allow for some kind of "chaining" of
configuration objects? That way items not found in the first
configuration might be found in later ones.

In most of my projects that use configuration files, there are a set
of hard-coded defaults for all configuration values. That way if no
config files exist, we still have a reasonable set of defaults
defined. A client creating a "default" configuration object that is
loaded with values from the program at initialization time and chained
on the back would be one way of implementing this.

> > Question: Is the file closed (w.r.t. the OS) between the end of the
> > read and the start of the write?
> 
> Yes. Actually, I think the file is OS closed at the end of Open, after
> the data is read in.

*That* sounds like an implementation detail to me. Its a good idea
perhaps, but still an implementation detail.

> I'm planning on renaming the file to a backup name before writing it,
> for glitch protection.

Ditto

> base64 would be good for values that don't need to be user editable. I
> guess persistent storage for a large object (whether it is composite
> or not) could be supported that way. I'm not clear why that would be
> in a typical "config file". Hmm, maybe a pixel bitmap for an icon?

Motif's UIL did these as text. You define the colormap for each ASCII
character, then use the defined ASCII characters to draw the bitmap.
In the text buffer it looked a bit like ASCII art. The only big
drawback I saw was that the "art" value is destroyed if your bitmap
gets wider than your text editor.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: config files proposal

[Darren New]

Ted Dennison wrote:
> > > Question: Are keys case-sensitive?
> >
> > Good point. I think I'll go with the Ada identifier model and say
> > "no".
> 
> I agree wholeheartedly, for the same reason.

I think they should be case sensitive unless there's a standard way of
converting uppercase unicode to lowercase unicode in Ada's libraries.
Remember that (for example) you'll probably want to store this stuff in a
Map, implying a hashtable perhaps, meaning you'll need to convert between
whatever is supplied and either upper or lower case, and do so in the same
way a native speaker of the language would do so.

Remember too that (for example) the lower-case version of some German words
don't even have the same length as the upper-case version. And I'm not even
sure there's general agreement on whether uppercase letters in French have
the accent included or not. And I don't even *know* if there is the
equivalent with different Chinese, Japanese, or Cyrilic characters, for
example.

While it's admirable to ignore the case of the letters, I think trying to
implement a general "to_lower" that'll handle Unicode properly is going to
be more of a nightmare than writing the entire rest of the config file
parser. Unless you restrict the keys to US-ASCII, that is.

Just something to consider. 
 
> Perhaps it would be better to allow for some kind of "chaining" of
> configuration objects? That way items not found in the first
> configuration might be found in later ones.

Yes, I think that's a good way to go also. At least, that's how I do it. :-)

I think there should also be some sort of tag at the front of each file
saying it's an Ada config file, even if only

 -- Ada Grace.Config file V1.0 -- Do not hand-edit.

so one could check you've found a proper file and know what version it is.

> > Yes. Actually, I think the file is OS closed at the end of Open, after
> > the data is read in.
> 
> *That* sounds like an implementation detail to me. Its a good idea
> perhaps, but still an implementation detail.

I think it's an important detail for systems where having a file open
changes the semantics for other users. If, for example, you leave it open
after you write it, it's possible I won't be able to read it. If you leave
it open after reading it, I may be dedicating resources on the file server
to keeping track of it (assuming it's centrally served, for example).
Closing it each time would make it easier to reason about multiple users
using the same config file, and the overhead of reopening it should be
minimal, given it's a config file.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Jean-Marc Bourguet]

Darren New <dnew@san.rr.com> writes:

> While it's admirable to ignore the case of the letters, I think trying to
> implement a general "to_lower" that'll handle Unicode properly is going to
> be more of a nightmare than writing the entire rest of the config file
> parser. Unless you restrict the keys to US-ASCII, that is.

Well unicode define canonical forms (4 of them: x2 for the case
issues, x2 for determining if things like "superscript 2" and 2 are
equivalent).  And you are right, the case independant canonical forms
are dependent on the locale.

But even for case dependant comparisons, using canonical form is
needed as some glyphs have multiple representations.

Yours,

-- 
Jean-Marc

Re: config files proposal

[Darren New]

Jean-Marc Bourguet wrote:
> But even for case dependant comparisons, using canonical form is
> needed as some glyphs have multiple representations.

OK. Does Ada define Unicode libraries that let you work with this? Does
GNAT? :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Preben Randhol]

On Mon, 03 Jun 2002 16:50:41 GMT, Darren New wrote:
> Jean-Marc Bourguet wrote:
>> But even for case dependant comparisons, using canonical form is
>> needed as some glyphs have multiple representations.
> 
> OK. Does Ada define Unicode libraries that let you work with this? Does
> GNAT? :-)

http://sourceforge.net/projects/ngeadal/

Preben

Re: config files proposal

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3CFB94A7.A455B8DD@san.rr.com>...
> I think they should be case sensitive unless there's a standard way of
> converting uppercase unicode to lowercase unicode in Ada's libraries.

We need to match up well with what's in the Ada standard I think. 

The Ada standard has an Ada.Strings.Maps.Constants.Lower_Case_Map and
an Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map. There is no
reason why we can't define things to say that keys will be fed through
the appropriate Lower_Case_Map before being matched.

If the language itself has some kind of problem with
Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map, I say that is the
language's problem, and outside the scope of a configuration item
facility to try to worry about fixing. As long as we define what we
are doing carfully this way, it is still explicit. If we stick to
using the standard library, things should at least behave for people
the way they have come to expect them to behave when using Ada.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: config files proposal

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Darren New <dnew@san.rr.com> wrote in message
> news:<3CFB94A7.A455B8DD@san.rr.com>... 
> > I think they should be case sensitive unless there's a standard way of
> > converting uppercase unicode to lowercase unicode in Ada's libraries.
> 
> We need to match up well with what's in the Ada standard I think. 
> 
> The Ada standard has an Ada.Strings.Maps.Constants.Lower_Case_Map and
> an Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map. There is no
> reason why we can't define things to say that keys will be fed through
> the appropriate Lower_Case_Map before being matched.

Good point.

> If the language itself has some kind of problem with
> Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map, I say that is
> the language's problem, and outside the scope of a configuration
> item facility to try to worry about fixing. As long as we define
> what we are doing carfully this way, it is still explicit. If we
> stick to using the standard library, things should at least behave
> for people the way they have come to expect them to behave when
> using Ada.

According to my interpretation of recent posts by Robert Dewar (is
that qualified enough :), there is very little use of Wide_String. So
it's not clear whether Lower_Case_Map is "what people expect". But I
agree it would be a good place to start. 

Perhaps case sensitivity should be an option in the config file API.

-- 
-- Stephe

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> I think there should also be some sort of tag at the front of each file
> saying it's an Ada config file, even if only
> 
>  -- Ada Grace.Config file V1.0 -- Do not hand-edit.

Part of the point is to _allow_ hand editing :).

> so one could check you've found a proper file and know what version
> it is.

Yes, I'm leaning towards a standard implemntation of config file
versions. If only to hint to application builders that they should
consider versioning issues! It's easy to do in the root tag of an XML
document. 

> > > Yes. Actually, I think the file is OS closed at the end of Open,
> > > after the data is read in.
> > 
> > *That* sounds like an implementation detail to me. Its a good idea
> > perhaps, but still an implementation detail.
> 
> I think it's an important detail for systems where having a file open
> changes the semantics for other users. 

Not for config files. These are _explicitly_ not accessible by
parallel processes.

Hmm. Guess I have to allow read-only parallel access if I'm allowing
system-wide config files. Sigh. Why do things have to be so
complicated?

So yes, the file is closed at the end of an open operation.

> If, for example, you leave it open after you write it, it's possible
> I won't be able to read it. 

Arg. Who gets to write a system config file? This is why I wanted to
exclude parallel access. 

> If you leave it open after reading it, I may be dedicating resources
> on the file server to keeping track of it (assuming it's centrally
> served, for example). Closing it each time would make it easier to
> reason about multiple users using the same config file, and the
> overhead of reopening it should be minimal, given it's a config
> file.

Yeah, I think closing it after each open and flush should be required.

This will still depend on OS file system locking for preventing read
while someone has a file open for write. That is _not_ required by the
config file API, so we can use it on a primitive OS like VxWorks (hmm,
maybe VxWorks has file locking?) or DOS. But it is an added feature of
using a real OS.

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > I think there should also be some sort of tag at the front of each file
> > saying it's an Ada config file, even if only
> >
> >  -- Ada Grace.Config file V1.0 -- Do not hand-edit.
> 
> Part of the point is to _allow_ hand editing :).

Right. But it should still be marked "don't do that". Or maybe "Read manual
before hand-editing". ;-)

> > I think it's an important detail for systems where having a file open
> > changes the semantics for other users.
> 
> Not for config files. These are _explicitly_ not accessible by
> parallel processes.

Um... So, if my config file is open, and thus my backup program doesn't back
it up, is that good or bad? If a program is running that only reads config
files, should I be allowed to copy the config file it uses to a different
directory while it's running?

I'm not just talking about multiple users of the config file API trying to
write at the same time.

> Hmm. Guess I have to allow read-only parallel access if I'm allowing
> system-wide config files. Sigh. Why do things have to be so
> complicated?
> 
> So yes, the file is closed at the end of an open operation.

Yeah. Just so much eaiser. :-)
 
> > If, for example, you leave it open after you write it, it's possible
> > I won't be able to read it.
> 
> Arg. Who gets to write a system config file? This is why I wanted to
> exclude parallel access.

Well, *somebody* has to write it, yes? I'm just saying that not all the
world is UNIX, and not every OS defaults to letting you edit files that are
already open.
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Preben Randhol]

On Mon, 10 Jun 2002 01:33:28 GMT, Darren New wrote:
> Right. But it should still be marked "don't do that". Or maybe "Read manual
> before hand-editing". ;-)

No it should not read "Don't handedit" if you will allow the user to do
this. It should be the latter you said. The reason is that for the files
that you don't want a user to hand edit you should reserve the "Don't
edit". Then the user understands that it is serious.

Preben

Re: config files proposal

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Stephen Leake <stephen_leake@acm.org> wrote in message
> news:<wkznydwcm7.fsf@acm.org>...
> > Darren New <dnew@san.rr.com> writes:
> > > You need to specify where a file is written in the path. (API#6)
> > > apparently only talks about reading files.
> > 
> > It should be written where it is found; I'll add that. Hmm, special
> > case if it is a new file; write it to the first directory in the
> > search path.
> 
> Perhaps I'm misunderstanding, but this sounds to me like you are
> saying:
> 
>   1)  Users have very little control over where their config files get
> written to.

Perhaps. The config file API allows the application to specify a
search path (possibly two; one read-only). It's up to the application
how much control to pass on to the user. I'd like the config file
package to support the widest range of scenarios (even ones I don't
like :).

>   2) There will be only one config file per system. 

Not true.

>   3) The facility will be dependent on the very system-dependant
>   feature of directory search paths.

No need for this to be system dependent. In my draft spec, I represent
a search path by a list of strings.

In any case, the body of a config file implementation may very well be
system dependent; Ada.Text_IO is probably not up to implementing this
spec.

> I don't like the first two ideas at all, since they needlessly
> restrict the funtionality. 

Right; that's why they aren't there :).

> I could easily see loads of people who would otherwise love to use
> the facility, forced to roll their own due to problems with 1 and 2.

Please check back when I post the draft spec; that will probably make
it clearer.

> Clients of the facility should be able to read and write
> configurations to and from the directories and file names of their
> choice.

Yes, that's true. But we also have to handle the situations that
Darren is bringing up. An application should be able to use both
system-wide and user-specific config files. Users should _not_ be able
to edit system-wide config files, but they _should_ be able to read
them, as defaults that are overridden by their user-specific files.

> The third issue I think requires a good deal of discussion before
> being accepted. For one thing, it will prevent anyone from making a
> portable implementation of the config file facility. 

Well, using GNAT.Directory_Operations makes it portable in one sense.

100 % portable across operating systems is not possible. Some sort of
accomodation must be made for file and directory access on different
operating systems.

> It should also be noted that if this facility's behavior depends on
> an implementation-defined facility, then you are basicly saying that
> (part of) this facility's behavior is implementation-defined. 

That is certainly undesirable. But I think that as long as terms like
"directory" and "file" are well-defined, we should be ok. Note that
the MAC tends to blur these a little; a "file" has a "resource-fork"
and a "data-fork" (I think those are the right terms :).

> That in turn means programs that use this facility are going to have
> portability issues. In my mind, that's more serious than having
> non-portable config files.

Yes. The config-file API is intended to be completely portable.

> > > FF #3 I would disagree with. It limits having large items in the
> > > config file format.
> > 
> > Only if there is a maximum line length. I guess some text editors
> > might impose one, but Ada.Text_IO doesn't.
> 
> Since it requires that the user supply a fixed-length buffer,
> Ada.Text_IO effectively *does* impose a limit. It just lets you decide
> what that limit is. :-)

As has been discussed before on cla, there are ways around this.

> > > Making key/value pairs terminated by a newline is specifying the
> > > implementation.
> 
> I'd disagree with this statement. It is (partially) specifying a file
> format, but in no way specifies how the config file facility
> implements it. The file format *has* to be part of the specification,
> it can't be left as an "implementation detail".

Exactly.

> Presumably this is just a first cut to get the "easy ones" ironed
> out, before we start to agree on a file format. Right?

Yes.

> If so, a lot of this discussion will be rendered moot when the file
> format is decided upon.

Yes.

> > I'm not sure what your question is. Oh, I see; you want me to request
> > key "foo", and if not found in ~/.bashrc then look in /etc/bashrc to
> > find "foo". Hmm.
> > 
> > I guess we could add an "append_read_only" operation, that would read
> > in a second file, and store it in a separate read-only tree. I like
> > that. 
> 
> Perhaps it would be better to allow for some kind of "chaining" of
> configuration objects? That way items not found in the first
> configuration might be found in later ones.

That's what I was trying to say. There needs to be more than two files
in the chain, but only one (the first one?) is writeable.

> In most of my projects that use configuration files, there are a set
> of hard-coded defaults for all configuration values. That way if no
> config files exist, we still have a reasonable set of defaults
> defined. A client creating a "default" configuration object that is
> loaded with values from the program at initialization time and
> chained on the back would be one way of implementing this.

Yes, that's what I'd like to support.

> > > Question: Is the file closed (w.r.t. the OS) between the end of
> > > the read and the start of the write?
> > 
> > Yes. Actually, I think the file is OS closed at the end of Open, after
> > the data is read in.
> 
> *That* sounds like an implementation detail to me. Its a good idea
> perhaps, but still an implementation detail.

Yes, it is.

> > base64 would be good for values that don't need to be user editable. I
> > guess persistent storage for a large object (whether it is composite
> > or not) could be supported that way. I'm not clear why that would be
> > in a typical "config file". Hmm, maybe a pixel bitmap for an icon?
> 
> Motif's UIL did these as text. You define the colormap for each ASCII
> character, then use the defined ASCII characters to draw the bitmap.
> In the text buffer it looked a bit like ASCII art. The only big
> drawback I saw was that the "art" value is destroyed if your bitmap
> gets wider than your text editor.

I'd like to have a general "binary data - not human editable" data
type. Maybe with an Ada Streams interface?

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> Note that
> the MAC tends to blur these a little; a "file" has a "resource-fork"
> and a "data-fork" (I think those are the right terms :).

So does Windows. (Under NTFS at least.) It's just that nobody uses them.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Ted Dennison]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkr8jgrya2.fsf@acm.org>...
> I'd like to have a general "binary data - not human editable" data
> type. Maybe with an Ada Streams interface?

An intersting idea. But if you have a separate data type for binary
data, don't you open the door for other data types, eg: Float,
Integer, Duration, Date/Time, etc?


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: config files proposal

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Stephen Leake <stephen_leake@acm.org> wrote in message
> news:<wkr8jgrya2.fsf@acm.org>... 
> > I'd like to have a general "binary data - not human editable" data
> > type. Maybe with an Ada Streams interface?
> 
> An intersting idea. But if you have a separate data type for binary
> data, don't you open the door for other data types, eg: Float,
> Integer, Duration, Date/Time, etc?

Well, we already have "approved" interfaces for scalar types.

Yes, the user could abuse the binary interface to store a Date, rather
than adding an appropriate interface for Calendar.Time. That's not bad
as a quick work-around.

My motto for this is "I need the power to shoot myself in the foot,
and the discipline not too". 

-- 
-- Stephe

Re: config files proposal

[Preben Randhol]

On Sun, 02 Jun 2002 22:16:00 GMT, Stephen Leake wrote:
> Darren New <dnew@san.rr.com> writes:
> 
>> Stephen Leake wrote:
>> Question: Would it make sense to allow compound values to be written
>> by converting a stream of them to base64 or something?
> 
> I think composite values are best handled by multiple levels. Ie, if
> you have a record:
> 
> type Foo is record
>    a : integer;
>    b : integer;
> end record;
> 
> you write this as (assuming Java property style)
> 
> foo.a = 1
> foo.b = 2
> 
> base64 would be good for values that don't need to be user editable. I
> guess persistent storage for a large object (whether it is composite
> or not) could be supported that way. I'm not clear why that would be
> in a typical "config file". Hmm, maybe a pixel bitmap for an icon?

xpm is ASCII based.

If you start including base64 in the config files there will be a lot
of data corruption. If one need to use sth like that then the config
file should be binary so a user cannot edit it. The user of the package
can easily make more than one config file.

Example:

   User editable settings goes in settings.config
   Program settings (like coulours, variables) goes in program.data

Then program.data can be binary or whatever, while settings.config is
ASCII.

I don't think the package should know which OS it is running on. I mean
the developer should give it the propper Path to look in I think.

Preben

Re: config files proposal

[Antonio Duran]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkelfpy887.fsf@acm.org>...
> I've posted a summary of the requirements and options for a config
> file standard, at
> http://users.erols.com/leakstan/Stephe/Ada/config_files.html 
> 
> I'm going to experiment with an XML implementation before I post a
> draft spec; I suspect using XML for the file format will have an
> impact on the spec. If I find XML too complex, I'm leaning towards the
> Java property style.
> 
> Please comment on the requirements. 
> 
> Please don't say "just use the registry"; let's take that discussion
> as settled :). The consensus is we need both the registry and a
> simpler config file.
> 
> I'm on vacation starting Tuesday (back the following Monday), so I
> won't be responding to comments till then. I'll try to catch up on all
> of this thread when I get back, but feel free to send me email
> directly at stephen_leake@acm.org.

In relation to config files there are some points that I would like to
comment. I don't read the entire thread so please, forgive me if some
or all of them were previously discussed.

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. 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. When config file gets complicated enough one must write an
application to handle it (eg. Comanche to mantain Apache config
files).

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. 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?. 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.

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.

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?. 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?).

5. Regarding to the file syntax, long time ago I worked on a system
that runs on CAIS (Common APSE Interface Set). CAIS contains a List
Management package that provides great power for handling parameter
lists and those lists have a human readable text representation. That
text representation is, from my point of view, more Ada like and could
be used as a base syntax for config files. The example provided in the
Stephen requirements page would be (comments were not allowed in CAIS
Lists)

-- Config file TBD.

(
   -- ServerLayout Section.

   ServerLayout => (
      Identifier => "Default Layout",
      Screen => ("Default Screen", 0, 0),
      InputDevice => (
         "Generic Keyboard",
         "Configured Mouse",
         "Generic Mouse"
      ),
      Display => (
         Depth => 1,
         Modes => (
            (Width => 16#400#, Height => 768),
            (Width => 800, Height => 600) -- New mode added.
         )
      )
   ) -- End of ServerLayout section.
) -- End of config file TBD

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.

Antonio Duran

Re: config files proposal

[Darren New]

Antonio Duran wrote:
> 1. In my experience, most of the time, config files are writen, edited
> or modified by humans and read and interpreted by programs.

I think that's true on UNIX (esp. server programs) much more so than on
Windows. I can't remember the last time I edited configuration manually on
Windows.

> 2. ...

A good argument.

> 3. I think that is important to handle more than one config file in a
> single program.

Unquestionably.

> 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.

Errrr... if you ignore the ACLs on registry entries, sure. That's like
saying the problem with UNIX is it's all files, so if you can write to one
you can write to them all.

> 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.

I think it's also important to have system-wide, program-wide, and user-wide
config files.
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Antonio Duran]

Darren New <dnew@san.rr.com> wrote in message news:<3CFCE218.585D56E2@san.rr.com>...

> I think that's true on UNIX (esp. server programs) much more so than on
> Windows. I can't remember the last time I edited configuration manually on
> Windows.
> 

Maybe I'm not lucky enough since I recently had to configure Apache,
PHP, and MySQL on my machine and had to deal with text based config
files but these applications are not Windows native (that is, only for
Windows) ;-). Of course, using a text editor rather than a specific
tool is more error prone and one must take care of specific syntax
issues (eg. editing the hosts file and that tricky tab at the
beginning of entries).

> Errrr... if you ignore the ACLs on registry entries, sure. That's like
> saying the problem with UNIX is it's all files, so if you can write to one
> you can write to them all.

Right, I've ignored ACLs on registry entries (maybe because my
experience is on Windows 98). While I recognize the advantanges of
having configuration data in a single place (common tools for handling
data) I'm also concerned with, as we say in Spain, "putting all the
eggs in the same basket". There is a risk of loosing all your
configuration data. This is not only a Windows problem, as I recall,
on AIX there is also a repository for config data (I think its name is
RODM or something like that). Moreover, the data storage format of
those repositories is propietary, tailored to a specific system, and,
in general, even if you backed up your config data is complicated to
restore them back after a system crash.

While is true that on Unix, if you loose the contents of your /etc
directory you're in big trouble is also true that it contains ordinary
files and restoring them (provided you backed up them) is easier.

> I think it's also important to have system-wide, program-wide, and user-wide
> config files.

Agree.

Thank you for your answer and best regards,

     Antonio Dur�n

Re: config files proposal

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3CFCE218.585D56E2@san.rr.com>...
> Antonio Duran wrote:
> > 1. In my experience, most of the time, config files are writen, edited
> > or modified by humans and read and interpreted by programs.
> 
> I think that's true on UNIX (esp. server programs) much more so than on
> Windows. I can't remember the last time I edited configuration manually on
> Windows.

That's because of the way Windows is designed. With everything thrown
in one big database (the registry), the penalty for a user hosing the
configuration file is just too great to risk it. Every program *has*
to inlcude support for updating registry settings safely, lest they
risk their users hosing their entire system.

It doesn't sound like we are planning a "monolithic database"
approach, so this won't be an issue for us.

That said, I actually go into the registry manually myself lots, and I
know there are plenty of Microsoft support pages that specify
procedures involving manually updating the registry. The procedure for
setting up autologon in NT is an example.

> > 3. I think that is important to handle more than one config file in a
> > single program.
> 
> Unquestionably.

Then clearly we are *not* in the "one monolithic database" situation.

> I think it's also important to have system-wide, program-wide, and user-wide
> config files.

How "wide" they are should be up to the developer to set up and
support. However, the facility should allow for such setups. For
instance, if chaining is supported, then a Unix developer could put
the first file in ~, the second in the installation directory, and the
third in /usr/local somewhere.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Syntactically correct spanish identifiers (Was: config files proposal)

[Jacob Sparre Andersen]

Antonio Duran wrote:

> 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

Are you sure? I am almost certain that ISO-8859-1 is
intended for writing Spanish. It is also the character
encoding used for Ada source code.

But there are still good reasons to use English identifiers
in your Ada programs.

Jacob
-- 
"Vi f�r ikke andet sk�g end det vi selv kan finde p�."

Re: Syntactically correct spanish identifiers (Was: config files proposal)

[Robert Dewar]

Jacob Sparre Andersen <sparre@nbi.dk> wrote in message news:<3CFE62B5.BEC2ED6B@nbi.dk>...
> Antonio Duran wrote:
> 
> > 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
> 
> Are you sure? I am almost certain that ISO-8859-1 is
> intended for writing Spanish. It is also the character
> encoding used for Ada source code.

yes, of course, the default interpretation of type Character is Latin-1 which
includes all necessary characters for writing Spanish, and this is also the
default interpretation of program sources, so identifiers can be written in
Spanish with proper upper/lower case equivalences.

What would be interesting is to know is what you (Antonio) read that made
you think otherwise???

Re: Syntactically correct spanish identifiers (Was: config files proposal)

[Antonio Duran]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0206051749.558ed3fb@posting.google.com>...
> Jacob Sparre Andersen <sparre@nbi.dk> wrote in message news:<3CFE62B5.BEC2ED6B@nbi.dk>...
> > Antonio Duran wrote:
> > 
> > > 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
> > 
> > Are you sure? I am almost certain that ISO-8859-1 is
> > intended for writing Spanish. It is also the character
> > encoding used for Ada source code.
> 
> yes, of course, the default interpretation of type Character is Latin-1 which
> includes all necessary characters for writing Spanish, and this is also the
> default interpretation of program sources, so identifiers can be written in
> Spanish with proper upper/lower case equivalences.
> 
> What would be interesting is to know is what you (Antonio) read that made
> you think otherwise???

You are right, it is syntactically correct in Ada 95 to write
identifiers using acute vowels. I don't pretend to excuse myself but I
made the transition from Ada 83 to 95 and I skipped the first two
chapters of the LRM.

By the way, what I read, for general syntax subjects is the ANSI/MIL
STD 1815 from "Ada Compilers and Bibliography" (Cambridge University
Press).

I feel sorry for open an issue that only shows my ignorance. Next time
I will think before write. Thank you,
    
     Antonio Duran

Re: Syntactically correct spanish identifiers (Was: config files proposal)

[Robert Dewar]

antonio_duran@hotmail.com (Antonio Duran) wrote in message news:<e1a50f2.0206070007.68e343e@posting.google.com>...
> dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0206051749.558ed3fb@posting.google.com>...

> I feel sorry for open an issue that only shows my ignorance. Next time
> I will think before write. Thank you,

If lack of ignorance is defined as knowing everything that is in the RM,
then nearly all of us, including certainly me, are ignorant, so you don't
need to apologize :-)

Re: config files proposal

[Stephen Leake]

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

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> > 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.

Or simply allow an association of a comment string with each config value.
It gets filled in when read, or left out when written. It doesn't take XML
to do this.

-- This is comment one
key1=value1
-- This is comment two
key2=value2

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > > 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.
> 
> Or simply allow an association of a comment string with each config value.
> It gets filled in when read, or left out when written. 

The point would be to save the comments in memory, and write them out
again. That way, the comments can guide someone hand-editing the file.

We might as well let the app write comments via the API as well.

> It doesn't take XML to do this.

True; Ada can do anything :).

-- 
-- Stephe

Re: config files proposal

[Darren New]

Stephen Leake wrote:
> > Or simply allow an association of a comment string with each config value.
> > It gets filled in when read, or left out when written.
> 
> The point would be to save the comments in memory, and write them out
> again. That way, the comments can guide someone hand-editing the file.

Sorry. I meant "written out when written". Sheesh. OK, no more late-night
posting for me.

My intention was to say that one should be associating comments with keys,
not with arbitrary places in the INI file. Then, you wouldn't be restricting
yourself to a specific file format that can support (say) multiple
independent comments per key.

> We might as well let the app write comments via the API as well.

I think you need to be careful that you don't make the API too close to file
semantics. I.e., you want "here's a data structure, store it", rather than
"write this key/value, write this comment, write this other key/value, write
another comment, oh and another comment", I would think.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3D04C9D0.7DFCED9D@san.rr.com>...
> My intention was to say that one should be associating comments with keys,
> not with arbitrary places in the INI file. Then, you wouldn't be restricting
> yourself to a specific file format that can support (say) multiple
> independent comments per key.

Yeah, but then you can't make group comments, like:
  -----------------------------------------------------------
  -- The next few items set up system timeout values. Valid 
  -- values range from 0 to 120. The units are in seconds. 
  -- A timeout value of 0 indicates no timeout.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: config files proposal

[Darren New]

Ted Dennison wrote:
> Yeah, but then you can't make group comments, like:
>   -----------------------------------------------------------
>   -- The next few items set up system timeout values. Valid
>   -- values range from 0 to 120. The units are in seconds.
>   -- A timeout value of 0 indicates no timeout.

Sure. Any comment more than 76 characters wide gets wrapped on output.

> > -- This is comment one
> > key1=value1
> > -- This is comment two
> > key2=value2
> 
> True, but it complicates the parsing code significantly, while XML
> could handle it easily with some kind of attribute-comment tag.

Uh, it does? I don't *think* so. It seems quite straightforward to parse
such a thing.

My concern with the XML vs INI wrt comments is the possibility that it would
make the data structure rather complex. What API do you want to use to say
"I want section FOO to have two comments, then key1=value2, then another
comment"? All of a sudden, you're not manipulating a collection of keys and
values, but rather you're writing out streams of tokens. If each item in the
database is a 4-tuple of package, comment, key, value, then it's easy to
manipulate. If you start treating the database as a stream of values, where
you can have empty sections, sections with only comments, comments with no
keys associated, etc, you're going to have a much more complex API for no
real good reason other than to make it look like XML. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Volkert Barr]

Darren New wrote:
> 
> Ted Dennison wrote:
> > Yeah, but then you can't make group comments, like:
> >   -----------------------------------------------------------
> >   -- The next few items set up system timeout values. Valid
> >   -- values range from 0 to 120. The units are in seconds.
> >   -- A timeout value of 0 indicates no timeout.
> 
> Sure. Any comment more than 76 characters wide gets wrapped on output.
> 
> > > -- This is comment one
> > > key1=value1
> > > -- This is comment two
> > > key2=value2
> >
> > True, but it complicates the parsing code significantly, while XML
> > could handle it easily with some kind of attribute-comment tag.
> 
> Uh, it does? I don't *think* so. It seems quite straightforward to parse
> such a thing.
The problem here is not the parsing of an comment. The problem is to
what
kind of element the comment belongs. This information is needed, if i
want
my application to read, manipulate and write an configuration 
data from/back to a file without losing my comment information. Please,
i have 
set up a  small data model, which take this case into count (comment is
traditionally 
called description). Look at
http://swt.cs.tu-berlin.de/~barr/config_package.pdf.
If such a case should be handled, is is up to us to define a appropriate 
grammar.

Volkert

Re: config files proposal

[Darren New]

Volkert Barr wrote:
> > > True, but it complicates the parsing code significantly, while XML
> > > could handle it easily with some kind of attribute-comment tag.
> >
> > Uh, it does? I don't *think* so. It seems quite straightforward to parse
> > such a thing.
> The problem here is not the parsing of an comment.

Well, that was the problem being discussed, I think. :-)

> The problem is to
> what
> kind of element the comment belongs.

That's a good point. Sure, you'd want comments on sections and subsections
as well. That still doesn't need XML to implement. 

> http://swt.cs.tu-berlin.de/~barr/config_package.pdf.

Excellent start, I think!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Volkert Barr]

Darren New wrote:
> 
> Volkert Barr wrote:
> > > > True, but it complicates the parsing code significantly, while XML
> > > > could handle it easily with some kind of attribute-comment tag.
> > >
> > > Uh, it does? I don't *think* so. It seems quite straightforward to parse
> > > such a thing.
> > The problem here is not the parsing of an comment.
> 
> Well, that was the problem being discussed, I think. :-)
i had not engough time to follow the thread, so i was a bit ot 
ouf sync...  ;-)

> > The problem is to
> > what
> > kind of element the comment belongs.
> 
> That's a good point. Sure, you'd want comments on sections and subsections
> as well. That still doesn't need XML to implement.
> 
> > http://swt.cs.tu-berlin.de/~barr/config_package.pdf.
> 
> Excellent start, I think!
I have made an new update! 

Volkert

Re: config files proposal

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3D076CCD.A1F63320@san.rr.com>...
> Volkert Barr wrote:
> > > > True, but it complicates the parsing code significantly, while XML
> > > > could handle it easily with some kind of attribute-comment tag.
> > >
> > > Uh, it does? I don't *think* so. It seems quite straightforward to parse
> > > such a thing.
> > The problem here is not the parsing of an comment.
> 
> Well, that was the problem being discussed, I think. :-)

No, it wasn't.

> > The problem is to
> > what
> > kind of element the comment belongs.
> 
> That's a good point. Sure, you'd want comments on sections and subsections
> as well. That still doesn't need XML to implement. 

You're almost there. What I was trying to point out is that XML
doesn't really support it at all (at least not without adding some
kind of "commented-block" tag. Yeeach.).


> > http://swt.cs.tu-berlin.de/~barr/config_package.pdf.

Out of the 3 options presented there, I think the ".ini" looks the
best by far. The others just have way too much syntactic cruft
obscuring the important information.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: config files proposal

[Georg Bauhaus]

Volkert Barr <barr@cs.tu-berlin.de> wrote:
:  Look at
: http://swt.cs.tu-berlin.de/~barr/config_package.pdf.

Incidentally, for those who would like to have INI files,
here is an XSLT:

<!-- transform an XML configuration document into a Windows(TM)
     INI-style configuration text (may need refinements).

     Cannot handle the nested sections (are there nested sections in
     the INI file format?).

     See Volkert Barr's draft -->

<transform
  version="1.0"
  xmlns="http://www.w3.org/1999/XSL/Transform">

  <output method="text"/>

  <template match="/configuration">
    ;Configuration: <value-of select="@name"/>
    <apply-templates/>
  </template>

  <template match="description">
    ;<value-of select="normalize-space(.)"/> <!-- line breaking needed here -->
  </template>

  <template match="section">
    [<value-of select="@name"/>]
    <apply-templates/>
  </template>

  <template match="item">
    <value-of select="@*['key']"/>=<apply-templates/>
  </template>
     <!-- @*['key'] instead of @key to work around XSLT key() function  -->

 </transform>

With input copied from the example in the PDF, the output is


    ;Configuration: A_Configuration
  
    ;bla
  
    [A_Section]
    
    KeyX=ValueX
    
    [A_Subsection]
    
      
    ;bla bla
      Key1=Value1
      Key2=Value2
    
  
-- Georg 

Re: config files proposal

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3D03E1AD.80EB805D@san.rr.com>...
> Stephen Leake wrote:
> > > 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.
> 
> Or simply allow an association of a comment string with each config value.
> It gets filled in when read, or left out when written. It doesn't take XML
> to do this.
> 
> -- This is comment one
> key1=value1
> -- This is comment two
> key2=value2

True, but it complicates the parsing code significantly, while XML
could handle it easily with some kind of attribute-comment tag. What
you essentially have here is another attribute. One of my 2 things I
said we'd have to require out of the config language to make XML a
good idea was multiple tags per key. (The other was nested keys).

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: config files proposal

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: 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.

Incidentally, comments aren't lost in XML and each comment
belongs to an element. Namely, the element in which it appears.
There is a comment() function available to XPath expressions,
and a comment element type in XSLT for the creation of comment
nodes in the output.

(In SGML, things are even fancier. Comments are more Ada like,
except at both ends -- like so -- and they can appear in more
places than in XML.)

-- Georg

Re: config files proposal

[Darren New]

And for the folks wanting to use XML for this, here's what the IETF is 
thinking about using XML. Just an interesting draft.

http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-04.txt

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> And for the folks wanting to use XML for this, here's what the IETF is 
> thinking about using XML. Just an interesting draft.
> 
> http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-04.txt

Thanks, that looks very interesting. I'll read it later :).


-- 
-- Stephe

Re: config files proposal

[Volkert Barr]

I have also set up a small document. This should be merged with the work 
of Mr. Stephen Leake. I tried to contact him, but he did not replyed. 
Not to mention - this paper is in a very early stage, so it has 
several errors ;-). 

Hints and suggestions should be mailed to me 
(barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize 
them and send updates to c.l.a. for further discussion. 

See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf


Volkert

Re: config files proposal

[sk]

Hi, 

Volkert Barr <barr@cs.tu-berlin.de>
> ... of Mr. Stephen Leake. I tried to contact him, but he 
> did not replyed. ...

First message of this thread :

Subject: config files proposal
   Date: Sun, 02 Jun 2002 16:07:53 GMT
   From: Stephen Leake <stephen_leake@acm.org>

> I'm on vacation starting Tuesday (back the following Monday), 
> so I won't be responding to comments till then. 

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: config files proposal

[Volkert Barr]

> First message of this thread :
> 
> Subject: config files proposal
>    Date: Sun, 02 Jun 2002 16:07:53 GMT
>    From: Stephen Leake <stephen_leake@acm.org>
> 
> > I'm on vacation starting Tuesday (back the following Monday),
> > so I won't be responding to comments till then.
sorry!

Re: config files proposal

[sk]

Hi,

Nothing to be sorry about. Just thought I would
try to save you the anxiety of trying to contact
someone who is not there.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: config files proposal

[Volkert]

Volkert Barr <barr@cs.tu-berlin.de> wrote in message news:<3CFF15E7.9A697B40@cs.tu-berlin.de>...
> I have also set up a small document. 

An updated version can be downloaded!
 
> Hints and suggestions should be mailed to me 
> (barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize 
> them and send updates to c.l.a. for further discussion. 
> 
> See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf
> 
> 
> Volkert

Re: config files proposal

[Jason King]

A few thoughts on windows .ini style.
1)  The separator for value and key is '=' not ':='.  If we use an .ini 
file it should not break .ini file conventions.
2)  Standard .ini files use ';' as a comment to eol indicator, e.g.
; this is a comment
[section]
real1=val1
;real2=oldval2
real2=val2
Read/Write functions should ignore the lines that start with a ';'.

Volkert wrote:
> Volkert Barr <barr@cs.tu-berlin.de> wrote in message news:<3CFF15E7.9A697B40@cs.tu-berlin.de>...
> 
>>I have also set up a small document. 
> 
> 
> An updated version can be downloaded!
>  
> 
>>Hints and suggestions should be mailed to me 
>>(barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize 
>>them and send updates to c.l.a. for further discussion. 
>>
>>See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf
>>
>>
>>Volkert
> 

Re: config files proposal

[Preben Randhol]

On Fri, 07 Jun 2002 04:01:49 -0500, Jason King wrote:
> A few thoughts on windows .ini style.
> 1)  The separator for value and key is '=' not ':='.  If we use an .ini 
> file it should not break .ini file conventions.
> 2)  Standard .ini files use ';' as a comment to eol indicator, e.g.
> ; this is a comment

Yes but on unix it is very common that # is the mark for comments.

Re: config files proposal

[Darren New]

Preben Randhol wrote:
> 
> On Fri, 07 Jun 2002 04:01:49 -0500, Jason King wrote:
> > A few thoughts on windows .ini style.
> > 1)  The separator for value and key is '=' not ':='.  If we use an .ini
> > file it should not break .ini file conventions.
> > 2)  Standard .ini files use ';' as a comment to eol indicator, e.g.
> > ; this is a comment
> 
> Yes but on unix it is very common that # is the mark for comments.

If you're going to only allow alphanumberic keys, you might as well
accept ; # and -- as comments.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Preben Randhol]

On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote:
> If you're going to only allow alphanumberic keys, you might as well
> accept ; # and -- as comments.

Yes thought I would like to have only: -- 

Re: config files proposal

[Darren New]

Preben Randhol wrote:
> 
> On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote:
> > If you're going to only allow alphanumberic keys, you might as well
> > accept ; # and -- as comments.
> 
> Yes thought I would like to have only: --

Oh, I should also comment that if you're *not* going to follow the windows
.ini file format, chances are the default extension shouldn't be ".ini". :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: config files proposal

[Preben Randhol]

On Fri, 07 Jun 2002 17:33:53 GMT, Darren New wrote:
> Preben Randhol wrote:
>> 
>> On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote:
>> > If you're going to only allow alphanumberic keys, you might as well
>> > accept ; # and -- as comments.
>> 
>> Yes thought I would like to have only: --
> 
> Oh, I should also comment that if you're *not* going to follow the windows
> .ini file format, chances are the default extension shouldn't be ".ini". :-)

The package shouldn't care about the filename, just the content.

I like the :

Program.Name := Glosa
Program.Version := 0.8

etc...

more than the 
[Program]
Name=Glosa
Version=0.8

style too :-)

Re: config files proposal

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Oh, I should also comment that if you're *not* going to follow the windows
> .ini file format, chances are the default extension shouldn't be ".ini". :-)

note that on Unix, the notion of "file extension" is not built in to
the file system as it is on Windows. So I think the API should make no
mention of "file extension".

-- 
-- Stephe

Re: config files proposal

[Volkert]

Jason King <jhking@airmail.net> wrote in message news:<3D00767D.9020100@airmail.net>...
> A few thoughts on windows .ini style.
What if have done is a "Windows Ini like" definition. 

> 1)  The separator for value and key is '=' not ':='.  If we use an .ini 
> file it should not break .ini file conventions.
ok!

> 2)  Standard .ini files use ';' as a comment to eol indicator, e.g.
> ; this is a comment
i am with Prebens opinion here. 
 

Volkert

Re: config files proposal

[Ted Dennison]

Jason King <jhking@airmail.net> wrote in message news:<3D00767D.9020100@airmail.net>...
> A few thoughts on windows .ini style.
> 1)  The separator for value and key is '=' not ':='.  If we use an .ini 
> file it should not break .ini file conventions.

If I can take this as a comment that the above is closer to "true"
.ini style, if that's what he was trying to accomplish, then this is a
good comment.

However, I think it would be a big mistake to make rigid compatability
with Windows' .ini files a goal. For one thing, many if not most Ada
programs do not run on Windows. For another, that file format is in
thrall to Microsoft, and is probably only defined in Microsoft
copyrighted documents, if at all. Anything we come up with will have
to be something we can define with precision in the new LRM, without
having to worry about violating anyone's copyright, or having the
format change out from under us at the whim of one (non-Ada) vendor.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: config files proposal

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> However, I think it would be a big mistake to make rigid compatability
> with Windows' .ini files a goal. For one thing, many if not most Ada
> programs do not run on Windows. 

Possibly true, but not really relevant. If it's a good format, it will
be useful on non-Windows systems.

Perhaps you are implying "and therefore many people will not be
familiar with this format". That is probably true. But it's easy to
figure out!

> For another, that file format is in thrall to Microsoft, and is
> probably only defined in Microsoft copyrighted documents, if at all.
> Anything we come up with will have to be something we can define
> with precision in the new LRM, without having to worry about
> violating anyone's copyright, or having the format change out from
> under us at the whim of one (non-Ada) vendor.

Hmm. I'm not a copyright lawyer, but it seems like we can simply
define a syntax that looks like ini files. As long as we don't
actually read Microsoft documents in the process, we should be ok.
That's what the MingW people did for the Windows headers files.

But we should probably ask a lawyer about that, as has been said about
similar topics here recently.

-- 
-- Stephe

Re: config files proposal

[Stephen Leake]

Volkert Barr <barr@cs.tu-berlin.de> writes:

> I have also set up a small document. This should be merged with the work 
> of Mr. Stephen Leake. I tried to contact him, but he did not replyed. 

I guess I should have mentioned on the web site that I was on vacation
:).

-- 
-- Stephe

Re: config files proposal

[Antonio Duran]

I would like to raise a question that could be of interest regarding
config files. It only must be considered as a discussion point and I
am aware of the problems that can convey.

Form my point of view, in some cases it could be necessary/interesting
to keep configuration information confidential and to provide the
means to check the integrity of a configuration file.

Should the config file handling requirements make provisions for this
circumstances?

    Antonio Duran

Re: config files proposal

[Stephen Leake]

antonio_duran@hotmail.com (Antonio Duran) writes:

> Form my point of view, in some cases it could be necessary/interesting
> to keep configuration information confidential and to provide the
> means to check the integrity of a configuration file.

I'm not clear what you mean by "confidential". Clearly, the
application program that uses the config file must be able to read it.

If you mean that no other process/person should be able to read it,
that would be up to the operating system. If the OS provides access
controls to files, you can enforce confidentiality.

I think that issue has to be outside the scope of the Config_Files
API, since it depends heavily on the OS, and we want the Config_Files
API to be OS independent.


As for checking the integrity of the config file, that could be done
with an XML DTD and a validating parser. Come to think of it, that is
an advantage of using XML that I had not considered. Although, a
non-XML parser could also check integrity to the same degree.

Hmm. I'm not clear what you mean by "integrity". XML DTD's allow
specifying what values must be present, and to some extent what type
they are.

In other situations, "integrity" might mean a version control revision
number, or a checksum, or something similar.

-- 
-- Stephe

Re: config files proposal

[Antonio Duran]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uu1o7uuw1.fsf@gsfc.nasa.gov>...
> antonio_duran@hotmail.com (Antonio Duran) writes:
> 
> > Form my point of view, in some cases it could be necessary/interesting
> > to keep configuration information confidential and to provide the
> > means to check the integrity of a configuration file.
> 
> I'm not clear what you mean by "confidential". Clearly, the
> application program that uses the config file must be able to read it.
> 
> If you mean that no other process/person should be able to read it,
> that would be up to the operating system. If the OS provides access
> controls to files, you can enforce confidentiality.
> 
> I think that issue has to be outside the scope of the Config_Files
> API, since it depends heavily on the OS, and we want the Config_Files
> API to be OS independent.
> 
> 
> As for checking the integrity of the config file, that could be done
> with an XML DTD and a validating parser. Come to think of it, that is
> an advantage of using XML that I had not considered. Although, a
> non-XML parser could also check integrity to the same degree.
> 
> Hmm. I'm not clear what you mean by "integrity". XML DTD's allow
> specifying what values must be present, and to some extent what type
> they are.
> 
> In other situations, "integrity" might mean a version control revision
> number, or a checksum, or something similar.

What I meant with confidentiality and integrity was to use
cryptographic technics to encrypt/decrypt config files for
confidentiality and hash/digest for checking integrity.

I know this is far beyond the scope since by using that the file
couldn't be modified by hand with a simple text editor. My intent was
to know if that kind of functionality could be of interest in some
circumstances.

Antonio Duran

Re: config files proposal

[Stephen Leake]

antonio_duran@hotmail.com (Antonio Duran) writes:

> What I meant with confidentiality and integrity was to use
> cryptographic technics to encrypt/decrypt config files for
> confidentiality and hash/digest for checking integrity.

Ok, that's clear.

> I know this is far beyond the scope since by using that the file
> couldn't be modified by hand with a simple text editor. 

Yes.

> My intent was to know if that kind of functionality could be of
> interest in some circumstances.

Not to me, but it's a good question.

-- 
-- Stephe

Re: config files proposal

[Ted Dennison]

antonio_duran@hotmail.com (Antonio Duran) wrote in message news:<e1a50f2.0206130108.995ef66@posting.google.com>...
> Form my point of view, in some cases it could be necessary/interesting
> to keep configuration information confidential and to provide the
> means to check the integrity of a configuration file.
> 
> Should the config file handling requirements make provisions for this
> circumstances?

No. It sounds to me like you are arguing for an encryption/decryption
package. Then you could add use of it on certian keys as an option.
That might be a good discussion, but something as involved as
encryption wouldn't belong in a config file package.

Or are you just talking about "password" type data? Most OS's have
special calls to deal with that type of data. I suppose it would be
possible to write some kind of one-way encoding function in Ada.
However, that should still probably be in its own package.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)