Re: config files proposal

[Darren New <dnew@san.rr.com>]

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.