RE: [avrdude-dev] configuration file generation

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Joerg Wunsch
> Sent: Wednesday, March 23, 2011 4:51 PM
> To: address@hidden
> Subject: Re: [avrdude-dev] configuration file generation
> 
> Well, the yacc code has proven to be nothing like rocket science in
> the past: we've got a number of patches being submitted that extended
> it in some way.  By using XML, we'd just replace one prerequisite
> (yacc + lex) by another one (some XML library), so that's not much of
> an argument.  (Agreeing on a certain XML library API might cause more
> headache than agreeing on the yacc/lex interface which is pretty
> standardized.)

See, I told you: it would bring up all the same arguments again. :-)

I wasn't referring to a standard *interface*; yes yacc/lex is a standard 
infterface. The file format used for the config file is not a standard. No one 
else uses that. However, an XML file is at least some type of standard. Yes, we 
would be trading yacc/lex for some XML lib, so that's a wash.

 
> XML converters could be equally used to produce the current file
> format out of some well-structured XML file, and even out of
> not-so-well structured XML file ;-), see tools/*.xsl.

Point. Which is an argument for actually not changing a thing.

 
> Anyway, what bothers me most about the current format is not so much
> whether it's "standard" in some form or not, but the already mentioned
> sheer size (which makes it a little cumbersome to handle e.g. when
> cloning one device entry into another one), and the fact it does not
> employ some kind of hierarchical structure so a new tag name is needed
> for each parameter, even if the parameter applies to a completely
> different scope.
> 
> So, by no means, that doesn't mean I'm opposed to using XML.  At the
> very least, it would automatically give us a hierarchical structure.
> It's just I'm not really ecstatic about XML itself: it's pretty
> bloated after all.  (We could perhaps store the on-disk copy in the
> end-user's installation in a zip format, using zlib to extract it at
> run-time.)

Please, no. That just adds yet another library and prerequisite that we have to 
add to avrdude. Again, disk space is cheap.

If we have a configuration *directory*, which had in it multiple XML files, one 
for each device, then I think it would be simple to add a new device entry; 
just plop in a new XML file in the directory.

 
> Alas, rewriting all this is going to be a tedious work: it will
> replace one existing, *working* config file implementation by another
> one, with a lot of work to spend, which will *at best* yield just
> that: another working implementation.

Hey, look! We can agree! :-D

Yes, doing this would only give us marginal progress. I think that doing this 
feature would only buy us these advantages:

- Easier to add a new device entry. (Which may be nothing to sneeze at. At the 
rate that Atmel is coming out with new devices, this may be a very good reason.)

- Maybe (big if) easier for a novice to read / add to the configuration info.

- Slightly easier to customize / clone an avrdude setup. If there is one xml 
file per device, then you can prune out the devices that you don't work worth / 
don't care.

Any other advantages that I'm missing?

Eric