On Tue, 28 Jan 2003, Dieter Nützel wrote: > Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman: > > On Mon, 27 Jan 2003, Philip Brown wrote: > > > I am trying to point out that none of > > [-] > > > > On the other hand, > > > "DRI is meant to integrate with XFree86. XFree86 has a standard > > > configuration file format. We should follow the > > > 'principle of least surprise', and use the same format they are used > > > to for X11 configuration" > > > > > > DOES seem to make a good deal of sense, when considering the needs of > > > users as more important than the needs of developers. > > > > Two things: > > > > 1) Don't kick a gift horse in the mouth. If the users really want > > something in a certain way are more the happy to do it. > > > > 2) The XF86Config file format does what it does very well. It isn't > > necessarily what we are looking for. It also isn't exactly a library that > > one can just use. It is a very custom built parser for a very specific > > purpose. We don't need to re-invent the wheel here. > > Make the "file format" as simple as possible.
Absolutely. The XML "format" is already well known and very straight forward. A million and one tools exists for manipulation of these files. > Not only for the "users" but think about "remote" editing/managing even if it > is meant as a "local" config file. This was good "Unix thinking" for ages. Absolutely. XML is text based so any text editor can modify it. Assuming we can stick to your first request, then it only follows that it would be easy to do remotely with a simple vi session or ... X11 remote running of applications could do it graphically as well. > So what are the "technical" advantages of XML in this case? Quick List -- *) Text Based - easy to edit. *) Well known basic format (think each tag must be ended, etc.) *) Million and one tools already exist that handle XML if you didn't want to edit by hand. *) 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). *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. *) Assume that we have to in the future change the format specification: A simple XSLT file could transform the current into the other format without issues or having to write a bunch of C/perl/python code. 'nuff said? In some ways it is over kill. I have this philosophy though: If you do it right the first time and maybe go that extra mile you don't have to worry about it later. -- //========================================================\\ || 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
