Re: config files proposal

[dennison@telepath.com (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