Re: [avrdude-dev] avrdude.conf

[E. Weddington]

On 14 Feb 2003 at 23:44, Joerg Wunsch wrote:

<snip> 
> I don't necessarily say you need to put the information itself into
> the registry, but you'll probably need it to record the location of
> the files.

Ah, that was the mix up. I thought you were implying putting the data 
in the registry. Agreed on file location.

 
> . A central system-wide file that is not going to be customized but
>   keeps the central definitions (programming hardware, AVR devices).
>   This file can be updated in a new version without asking questions.
> 
> . A system-wide file that records system-wide defaults, like the
>   programming hardware that is (usually) connected to the system, the
>   port it is sitting on, and so on.  This file is initially missing
>   (so only compile-time builtins will apply), and will not be modified
>   by an update.
> 
> . Possibly a third file that overrides all this per user.  This is
>   meant to store a user's preference that is different from the
>   system administrator's view.  I guess this will be mostly absent,
>   but if we need to implement an override mechanism for file #2 above,
>   it wouldn't be hard to implement #3 as well.
> 
> Basically, the current avrdude.conf.sample is the contents of #1, but
> the purpose of combinde #1 & #2.  In order to preserve any local
> changes that are required for #2, Brian appended the .sample to the
> name, so he doesn't need to care about clobbering it during an
> upgrade.
> 
> File #1 above can again be installed without asking.  File #2 above
> needs to be established from information gathered from the
> administrator during installation.  File #3 is, again, normally
> missing, and will only be available if a user has certain requirements
> for overriding the system defaults.  Maybe it will never be used on
> Windows.

Agreed. As you said, I doubt #3 will ever be used on Windows.
 
> > This is one reason why I suggested perhaps using XML for the future.
> 
> I don't see how this would improve the situation.  You still need to
> differentiate between system-wide defaults, and the shipped
> configuration details that need an easy upgrade path when installing a
> new version.
> 
> That doesn't mean i'm totally against XML, it's a nice generic
> language, but i don't see what it would buy us right now, except from
> the need to write another parser construct.  The existing parser just
> works as it is, without much effort to maintain it (at least right
> now).

That's why I mentioned in another thread the expat parser lib:
http://sourceforge.net/projects/expat

But I agree that it's not necessary for now. That's why I had 
mentioned it for the future. But it might be a more user-friendly 
format for writing up custom programmer definitions.
 
> 
> 
> > A user could write a custom programmer 
> > definition without disturbing other definitions.
> 
> A user cannot write into a system directory. :-)

Ah well that blows it then.
 
> I see your point though, but you forgot that you then have to add
> something like an index file (so the software knows about an added
> definition), 

Not necessarily, I was assuming looking into the config subdir and 
reading all .xml files present; if it ain't there, it can't be used. 

>which is subject to the same considerations again as #1
> above...  You cannot easily upgrade the index file without risking to
> clobber system modifications.
> 
> XML or not, the option to split the configuration from one file out
> into many would be there using the yacc parser as well, if we really
> want that.

Well in theory we agree. I guess the main point I want to make is the 
KISS rule in any design. Keeping it simple will help Windows users 
and require less support. :-)

Eric