On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote:
Hi Bob,
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.
Regards,
Greg
Greg,
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
pmc altimus/mpc7500
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.
--Bob