[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avrdude-dev] configuration file generation
From: |
Weddington, Eric |
Subject: |
RE: [avrdude-dev] configuration file generation |
Date: |
Wed, 23 Mar 2011 17:20:06 -0600 |
> -----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