I should probably not be commenting, but I will anyway. ;) The groundswell of popularity of XML reminds me of the groundswell of popularity of Perl some years ago. (This isn't to say that Perl is any less popular today.) There seemed to be this sense of "Perl will solve everything you need," to the point of excess. One individual even proposed the notion of a Perl shell. Going back in time, there was a similar groundswell with C++. "Rewrite everything" was the mantra du jour. To take another cut on this, perhaps the format of /etc/hosts, /etc/passwd, /etc/shadow and so on should be changed to XML. And everything which interfaces with those files changed to suit. Yes, this was an attempt at reductio ad absurdum. ;) >From another perspective, let me submit the following. I'm on the nagios-users (www.nagios.org) mailing list. There have already been a few discussions encouraging the author to rewrite Nagios so that the config files are in XML. Because of the modular nature of Nagios, the "path of least resistance" option which seemed to rise to the top, was one of letting someone write a preprocessor. This preprocessor would parse XML files and produce native Nagios config files. This has 2 benefits: it allows the core developers to continue working on Nagios without getting sidetracked, and it will (eventually) allow XML folks to work within their familiar domain. The yum project doesn't appear (to me) to be on the same level of development complexity as Nagios, so the preprocessor approach might not be appropriate. I only make the suggestion as an alternative to help resolve the "less filling" vs. "tastes great" debate. ;) jc > -----Original Message----- > From: Michael Stenner [mailto:mstenner@xxxxxxxxxxxx] > Sent: Friday, May 30, 2003 8:12 AM > To: yum@xxxxxxxxxxxxxx > Subject: Re: [Yum] script run idea >=20 >=20 > First of all, Rob, I suggest that you prepend abstracts to emails > which exceed 50 lines (maybe that should be 100, I dunno). How about > 8 line abstracts, with each line under the standard 76ish character > limit? :) You can even do <abstract>I demonstrate the > necessity...</abstract> if you want :) >=20 > My take on xml is that it should usually be used IFF the primary > purpose of the data is to be read and written by machine, but human > reading or writing is considered valuable (but secondary). The gconf > stuff would be a perfect example. >=20 > Let me try and summarize your five points: >=20 > a) a standard config format would be good, and xml would be a good > choice for that >=20 > b) xml is well understood, other formats are inconsistent (maybe this > should be a.1) >=20 > c) xml is extensible, or MUCH easier to make extensible than > most hand-rolled alternatives >=20 > c) [ you probably meant d :) ] xml is easy to edit by hand >=20 > d) easy multi-purpose parsing and machine-editing >=20 > Basically, this comes down to a matter of opinion, but I think the > place where I disagree is with reason c, (the second one). I think a > lot of people find xml harder to read and edit than most other > standard config files. I find I often have trouble finding the data > amidst all that markup. This is just plain subjective, so I don't see > much point in discussing it into the ground. However, it's often the > dealbreaker for me. If I found xml as easy to read/edit as the > standard .ini format (like yum uses) then I would be completely with > you. >=20 > After all that, let me finish with this: I don't have an opinion > about which format should be used. I don't know enough (haven't been > following closely) about what it will do, how it will be used/edited, > and how extensible it needs to be. I just wanted to share my thoughts > on Rob's thoughts on xml :) And to pick on Rob a little. I wanted to > do that, too. >=20 > -Michael >=20 > --=20 > Michael Stenner Office Phone: 919-660-2513 > Duke University, Dept. of Physics mstenner@xxxxxxxxxxxx > Box 90305, Durham N.C. 27708-0305 > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum >=20
