On 18 Jan 2010, at 17:53, Alan McKinnon wrote:
...
XML allows you to generate complex, structured, hierarchical data
that
can be read, changed, and stored by well-tested third party libraries
that don't need to know anything about the contents or meaning of
your
configuration data beforehand. This means I, as a developer, don't
need
to write any code to read and parse configurations, validate the
syntax
or structure (only the content), or persist it back out.
In simpler terms: less time spent on the configuration parser, more
time
spent being productive.
...
Your post makes sense until you realise that the use of XML in a
configuration
designed to be changed by the user renders the package virtually
unusable.
Given a choice between me as a developer struggling with a config
parser
versus vast swathes of users dumping the package because of the same
parser,
I'd say it's me that has to work harder, not my users.
It pains me to be making another "I use a Mac" post here today, but
since I do so, I don't really see the pain.
I double click on an XML configuration file, and a GUI editor opens, a
program designed specifically for editing such files. I can create new
entries, child-objects of a configuration option, or I can just double-
click on the entry's value and change it. Strings, numbers & booleans
are clearly marked, so that I can't break my configuration file by
entering the wrong kind of data for a value.
Of course, I use Gentoo on my headless servers, so I am glad that
server software - Dovecot or Courier for IMAP, Apache, Samba - all
have plain-text configuration files I can edit with vim (which I have
been learning to utilise better recently). But even if these switched
to XML, a curses XML editor could easily be written.
As a novice programmer myself I was extremely glad to discover the
Getopt::Long (and similar) modules when learning Perl recently. I have
long written my scripts in Bash and parsed command-line parameters
myself, with $1 and shift and whatnot, and I'm sure I've created some
monstrosities with which it's easy for the user to foul things up just
by entering parameters in an unexpected order. So I'd be very glad to
hand off config script parsing to someone else - I write my software
for myself, so I'm not sure I care how this affects users ;). Having
said that, I'm a little surprised by Mike's assertion that there's no
libraries for parsing text configuration files that are comparable
with those for parsing XML.
Stroller.
