Re: Config_Files proposal

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

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

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

Ok. Do you think that prevents us from agreeing on which file format
to go forward with?

It's a pain maintaining two example implementations. The stuff we are
talking about here is totally independent of file format.

> What about values you don't change? 

As I said below, only values changed since being read from the config
file will be written; unchanged values are not written.

> What about values that you change back to match what's in
> /usr/local/app/config? 

Well, I guess we could provide an "undo" command. I guess "undo" can
simply delete the value from the writeable tree, which will expose the
value in the read-only tree (assuming there is one).

Perhaps also a total "erase", which would discard all changes.

> What about values you don't change but which came from ~/.myconfig?

Hmm. Good point. I guess all values from a writeable file must be
written, not just changed ones.

> 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, that is not implemented.

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

Right, it needs to be added.

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

Yes.

> Oh. One other question. How often are the config files read? 

When you call "open".

> If someone changes a config file while I'm running, do I see the
> change reflected? 

We explicitly rule out multiple parallel processes accessing the same
files. So that's erroneous usage, and you may format your hard disk :).

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

Don't do that.

Seriously, you've set up a race condition, which is an indication of
bad design. If you want multiple instances of your app running, each
with its own persistent window positions, you need multiple config
files. That is precisely one of my use cases, and why I argued for
specifying the config file on the app command line.

Or, if you really want one value shared among processes, use the
registry, since it is designed for that. 

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

Which is why we ruled out multiple processes from the beginning.

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

Ah. I guess I can rely on other Grace components. Good point.

> > Once again, thanks for your insightful comments.
> 
> Hey, it's fun. :-)

Less fun from this end :). But still Ok.

Let me ask again; can we choose the general file format now, or do you
think we need to work on the API more first?

-- 
-- Stephe