Philip Brown wrote:
I believe that the "people handy with a mouse" comment was referring to who the tools were for, not who would write them.If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes it *trivial* to write tools for people
handy with a mouse. Not to mention facilitating features like preventing
invalid configurations from being saved, and other stuff that comes
essentially free with XML.
The "writing tools" bit is handled already, given the existence of the xf86 config library. So "XML makes it easier to write tools" is an invalid argument. Not to mention that "people handy with a mouse", and not code, should not be writing tools for this stuff in the first place!
That aside, I fully plan to prototype out an initial version of the GUI tool in Python. Will I be able to use libxf86cfg? I have yet to see an answer either way.
The rules that are written for XML formats basically amount to little grammars. Learning the syntax of the grammar is pretty easy to pick up. It's a lot simpler than learning yacc, that's for sure! :) If it take you more than 20 or 30 minutes to pick it up, then you should quit ordering documentation in Egyptian hieroglyphs! :)And the "preventing invalid configurations" stuff is not "free". As I understand it, you have to write lengthy XML stuff to set rules, etc, etc.The argument was previously made, of "Well, we'll keep the XML syntax simple, so the bloated XML argument wont apply". I would think writing all the XML rules, and then having all the current developers have to *learn* all the XML syntax, so they can figure out what the heck is wrong with what they want to add to the config file, lands back in the "bloated XML" side.
The thing that makes most XML so unpleasant is the same thing that makes most HTML and most BASIC unpleasnt: it's written by people who aren't engineers. The thing that makes XML worse is that it gives people an extra degree of freedom. This amounts to giving people more rope with which to shoot themselves in the foot.
Whatever format is chosen, I think having some sort of rule-checker is a good idea. If we want to encourage 3rd parties to generate tools, then we really want to have a reference point to proove that everyone is working correctly. It's the same reason that most programming language standards bodies produce a reference parser as part of their work. If a user writes code that they belive should compile, but doesn't, they (and the compiler vendor) can refer to the reference parser. Having an authoritative source makes it a LOT easier to settle correctness arguments.
It is doable no matter what format we choose. One of the advantages of XML is that it will be easier to do, and it will be easier to maintain over time. Is that a significant advantage? Perhaps. Is that a big enough advantage to push us over to XML-land? Dunno.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
