the data would need to be well-formed at the time of change -- waiting until the data is needed would be too late. Secondly, what do you do if your configuration file (in its current manifestation) is corrupted or incorrect? Rhetorical question...
The point is largely moot. A developer can decide whether or not to his/her app will use an XML based config file -- perhaps a small cult of developers will decide this is how it should be done. But to handle the contents of/etc? That would take a monumental effort -- everything from login to bind to inetd would need to be rewritten. At that point, it would be better to step even further back and address the problems as "how to better design?" as opposed to "how to better piecemeal?"
"The Devil's Advocate has a less heard of, but tastier Foodcake" -- versil
Imagine if you were to convert everything in/etc to XML. think of all the apps that already know how to read those files -- they would have to be rewritten to know how to extract useful info from XML (eg: bind, login, the inetd). A very daunting task indeed. Still, I am not opposed to the idea. I see a whole new system emerging based on the linux kernel...
While it is true that XML is a data formatting language, its functionality extends greatly beyond that in ramifications.
I would argue in favor of ascii config files over binary config files. I will not elaborate why...maybe its a religious issue. I just wanted to point out that file locking and format correctness are issues that haunt both ascii and binary file formats and that validating XML is easy because you can require it to be well-formed.
And in response to If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction. Why not "write some integration code to (say) connect Linuxconf to XML so that it could manipulate any XML file with on-the-fly GUIs?"
As for the other software/data options people keep proposing; sometimes things need rebuilt, sometimes they dont -- sometimes we just need something new.
I have heard/participated in many a similiar conversation and have a couple of thoughts --
1) I see the real added value of XML config files as this. Ease of configuration through applications (scripted or some GUI or whatever). The great thing about XML documents is that they can be self describing. Markups like: could easily be used to create "on the fly" interfaces to modify any file. If created wisely, a DTD could provide enough generic ability to accomodate most any resource file (why not X resources too?). Then, it would be trivial (compared to establishing a DTD) to create UIs that need not care about the data, just the fields. 3) And another thing, why not use it to describe hardware and devices. 4) How about users and profiles? 5) I could rave forever...
The point is -- using XML has little impact on the actual data but would provide a common and pleasant way to interface with the data (ie: manipulate, read, interpret (you could have comment fields, hyperlinks to help files)) -- none of this is out of the scope of XML. It just needs some agreed upon standards and a few champions. Arent Mozilla config files already stored in XML? and are Slash's config files not also in XML(ish)?
remember: "Good ideas go to waste on those who already know the solution" -- versil
ps: Many posters are pointing out unwillingness to learn new things or to change from old ways on the part of developers. Tough. This is how the future moves.
Slashdot Mirror
The point is largely moot. A developer can decide whether or not to his/her app will use an XML based config file -- perhaps a small cult of developers will decide this is how it should be done. But to handle the contents of /etc? That would take a monumental effort -- everything from login to bind to inetd would need to be rewritten. At that point, it would be better to step even further back and address the problems as "how to better design?" as opposed to "how to better piecemeal?"
"The Devil's Advocate has a less heard of, but tastier Foodcake" -- versil
Imagine if you were to convert everything in /etc to XML. think of all the apps that already know how to read those files -- they would have to be rewritten to know how to extract useful info from XML (eg: bind, login, the inetd). A very daunting task indeed. Still, I am not opposed to the idea. I see a whole new system emerging based on the linux kernel...
I would argue in favor of ascii config files over binary config files. I will not elaborate why...maybe its a religious issue. I just wanted to point out that file locking and format correctness are issues that haunt both ascii and binary file formats and that validating XML is easy because you can require it to be well-formed.
And in response to If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction. Why not "write some integration code to (say) connect Linuxconf to XML so that it could manipulate any XML file with on-the-fly GUIs?"
As for the other software/data options people keep proposing; sometimes things need rebuilt, sometimes they dont -- sometimes we just need something new.
I have heard/participated in many a similiar conversation and have a couple of thoughts --
1) I see the real added value of XML config files as this. Ease of configuration through applications (scripted or some GUI or whatever). The great thing about XML documents is that they can be self describing. Markups like: could easily be used to create "on the fly" interfaces to modify any file. If created wisely, a DTD could provide enough generic ability to accomodate most any resource file (why not X resources too?). Then, it would be trivial (compared to establishing a DTD) to create UIs that need not care about the data, just the fields.
3) And another thing, why not use it to describe hardware and devices.
4) How about users and profiles?
5) I could rave forever...
The point is -- using XML has little impact on the actual data but would provide a common and pleasant way to interface with the data (ie: manipulate, read, interpret (you could have comment fields, hyperlinks to help files)) -- none of this is out of the scope of XML. It just needs some agreed upon standards and a few champions. Arent Mozilla config files already stored in XML? and are Slash's config files not also in XML(ish)?
remember: "Good ideas go to waste on those who already know the solution" -- versil
ps: Many posters are pointing out unwillingness to learn new things or to change from old ways on the part of developers. Tough. This is how the future moves.
suse 6.1 gives you the option of installing a 2.2 or a 2.0 kernel.