On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote:
The config language does lend itself to XML, (and it was my first
thought when Ron suggested a new languge) but I would recommend
against it for a couple of reasons. The first is that the language
needs to serve the dual purpose of specifying *and documenting* a
particular configuration. XML is great for the former, but is almost
impossible to read easily, particularly for people not used to
working with it. Sure, you could then add something that converts the
XML into a more readable document, but then what is a simple idea is
now becoming very complicated. Secondly, and more importantly, is
that it would mean that LB relies on the existence of an extremely
complex external component, that is out of the control of the LB
community (be it pyRXP, libXML, or whatever). Arguably this is
already the case, since the configuration process uses python, but if
we adopt a new configuration language then the parser can be included
as part of the distribution - making it effectively self-contained.
So in my view the limitations of using XML outweigh any advantages
that might be obtained.
Y'know, it's *OK* to say "I just don't like it". :-)
I know if Ron & y'all don't *want* to do it it won't
get done, which is, again, *OK*. :-)
But understanding that I don't seriously expect this
to happen in LB, I do sort of want to respin a
couple of your points...
It's interesting what you say about documentation, because
one of the oft-cited primary advantages of XML is that
it is self-documenting. Perhaps it takes some getting used
to but in the end the meaning of:
<pmc vendor="altimus" model="mpc7500">
has got to be at least as clear as
even if it is a bit more longer.
Beyond this, the formal specification for an XML document
is in the DTD (or schema): an overt, external data file
that all code can reference. With a config file of the
sort that LB has had thus far, the real specification is
embedded in the parser source code, perhaps supplemented
by usage notes. Thus it is fairly easy for disconnects to
occur not only between the implmentation and the user's
understanding thereof, but between the written, external
documentation and the implementation.
The reliance on an external library is, I would think,
something of a red herring. As you point out, there are
myriad external libraries that are being relied upon. A
yacc/lex implementation relies on the implementation of
yacc & lex and all the lexical arcania that come with
them. Ron suggested YAPP, which relies on the YAPP
project. In the case of PyRXP, that whole thing is GPL'd,
so if the project wanted, a version of PyRXP could be
frozen into the LB CVS tree. Granted, that could mean
fixing it if it turns out to be broken, but that's a
separate issue from the one you cited, and is probably not
a significantly greater a risk than exists with many
other parser generators that could be chosen.
The one other thing I'll add is that, while existing LB
developers may not be well-versed in XML, the fact is that,
industry-wide, XML literacy is growing if not exploding. In
the long term, finding people who understand and can work
with XML will be no harder, and probably easier, than
finding people who can program in C. A custom configuration
language, and the code to implement it, will be novel to
everyone who encounters it, now and forever.
Just my $0.02.