Ian, Comments are inline below and I have also included a couple of one line responses you posted to the list. I like to keep the traffic on the list as reasonable as possible so that is why I am not replying to them individually.
On Tue, 28 Jan 2003, Ian Molton wrote: > On Tue, 28 Jan 2003 02:55:22 -0600 (CST) > "D. Hageman" <[EMAIL PROTECTED]> wrote: > > > > > So what are the "technical" advantages of XML in this case? > > > > Quick List -- > > > > *) Text Based - easy to edit. > > Text based does NOT imply easy to edit. look at USBsnopys' output. its > completely illegible. My intent with this point was that you can edit it with any text editor of your choice. It doesn't require a hex editor or *necessarily* *require* a graphical tool. The graphical tool here is one of the main goals of this endeavor as Ian Romanick pointed out. > > *) Well known basic format (think each tag must be ended, etc.) > > Not a valid argument. no two schemas are alike. Alan Cox hit on exactly what I was getting at with this point, so no need for me to rehash it. > > *) Million and one tools already exist that handle XML if you didn't > > want to edit by hand. > > Way more code than necessary. bloat. I don't see why this adds bloat to what we are doing. I am saying that many tools already exist to handle XML wether it be editing or something else. It kinda points out that we aren't re-inventing the wheel or something. It also kinda says that it isn't going away tommorrow. > > *) Every major programming language has some library to handle XML > > (say if you hacked togther a library that does the XF86Config file > > format ... this wouldn't be the case). > > Irrelevant in this case. Very relevant. While one of the projects goals is to provide a tool somebody else (think Gnome or KDE) will most likely implement their own interface. They can use whatever they need to implement it and they aren't constrained by some decision that the developer makes. > > *) Extensible, no painting ourselves into a corner. One can easily > > extend the spec without having to rewrite the entire parser. > > Also irrelevant. the USERS will never need to do this. No, but we, the developers will most likely need to do this since I have found predicting the future to be quite difficult. If I could I could make much more money off the stock market. Like I stated one of the goals is to provide a cute little control panel like gui for the end user. If they are a power user and want to edit it with a text editor they are more then welcome to. > The parser is also non-trivial. Parser is already written and from the way things are looking won't be tossed by the wayside anytime soon. >> what alternative do you propose that would be faster? Are we talking >> seconds, minutes, hours ... what? > >On some systems, every nanosecond counts. I am willing to bet those systems aren't doing 3D graphics ... At any rate - the cost of parsing is incurred at program startup and then goes away. >> Hence the GUI ... I think I have covered all the arguments that needed >> to be addressed. > >Um. this is unix. dont forget the command line. I think we already addressed this too many times already. -- //========================================================\\ || D. Hageman <[EMAIL PROTECTED]> || \\========================================================// ------------------------------------------------------- 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
