Re: Config_Files proposal

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

Stephen Leake wrote:
> That isn't what I meant to say :). The API _is_ orthogonal to the file
> format.

I don't think the API covers everything you'd want yet.
 
> > That said, there's some things missing from the spec:
> >
> > 1) When you read three config files off the path, change a value that was in
> > the second one, and write it out again, where does it get written?
> 
> I tried to answer that in requirement 10, but I can see it isn't very
> clear.
> 
> The intent is that only one file be writable, and that is where all
> values are written.
> 
> For example, if you open ~/.myconfig (writable), /usr/local/app/config
> (readonly) and /etc/app/config (readonly), then any values you change
> are written to ~/.myconfig.

What about values you don't change? What about values that you change back
to match what's in /usr/local/app/config? What about values you don't change
but which came from ~/.myconfig?

There's no obvious place I saw in the .ADS that shows multiple file names
being offered for reading, such that they'd be linked in any way.

> Yes, but any values the user changes will be written to the local
> file. Same example as above.

OK. That isn't clear from the docs. At least not to me.
 
> > 3) If you enable #2, and then the user changes her email address,
> > does it also store back the mail server address, thereby preventing
> > the administrator from changing it?
> 
> Hmm. I was going to say "no, the user did not change that value". That
> is my intent. But my draft implementation does not follow that intent;
> it writes all the values to the writeable (local) file.
> 
> I'll declare that implementation broken, in this respect. I guess I
> need a "value changed since read" marker, and only changed values get
> written.

Still not good enough. If I change the user email address this session,
write it out, then change the window position next time, I don't want to
lose the email address when I write it.

I think you need to keep track, for each value, what file it was read from
and whether it changed. Then when you write it out, write out any values
that have changed as well as any values that originally came from the file
you're rewriting.

> Hmm. Now I think we need the queries "what file was this value read from"
> and "what file will this value be written to".

Something close to that, yes. :)

Oh. One other question. How often are the config files read? If someone
changes a config file while I'm running, do I see the change reflected? What
if I run two copies of the app at once, one of which I use to configure a
bunch of stuff, then write it back out, and the other which I move a window
but don't change anything else. Does it reread the "changed" file, make the
updates, and write it back out? 

I think if you're not careful, there's going to be very unintuitive
behavior.

> but not in the visible part of the spec). Since the same effect can be
> accomplished via numbered keys, I don't think it's worth pursuing at
> this time.

Fair enough.
 
> Hmm, I'm wrong. There is a requirement to return "a list of keys". I
> guess that will be a list of strings. When I implement that, I'll
> think about this issue again :).

I'd think an unconstrained array of strings would be best there. Of course,
if it's part of Grace, you have th elists.
 
> Once again, thanks for your insightful comments.

Hey, it's fun. :-)

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