On Friday 18 November 2005 09:46am, Răzvan Corneliu C.R. "d3vi1" VILT wrote: > On Fri, 2005-11-18 at 00:20 +0200, Gilboa Davara wrote: > > I, too, second the "anything but XML" statement. > > A. Hard to read. > > B. Hard to edit using non-XML editors. (vim in my case) > > C. Tends to create needlessly-complex data structures. > > D. While can be accessed using shell scripts, it requires very complex > > and unreadable code. > > > > On the other hand, what does XML offer in return? > > > > Gilboa > > I don't second that. Today XML is the format everybody uses. Why? > Because it's a standardised way to put any kind of information in a > text-file. No. Everybody uses it because product managers come along and say we have to have XML on "the box" or because programmers are too lazy to write a parser. Don't get me wrong...XML is *wonderful* for certain things. Configuration files for UNIX/Linux daemons is not one of them. > A. Depends on how the schema is created. XML files can be easy to read > or dificult. Identing the xml code always helps. Exactly right. Unfortunately, 99% of it seems to go to the "difficult" end of the scale. > B. Colored syntax always helps. That's all you usually need. At least > it's enough for me. I must say that Midnight Commander seems to work > with XML a little better. I haven't tried it with mc, but I agree...chromacoding is (almost) always helpful for any kind of text file; shell scripts, C/C++, perl, XML, httpd.conf, /etc/fstab, DNS zone files, etc., etc., etc. XML is not special in this regard. Also, I will reiterate what others have pointed out, properly indenting (using tabs/indents and NOT spaces) is extremely helpful. Yeah, I know; in some groups of users, good luck defining "properly" in that statement. > C. Depends on the schema. Right; unfortunately, people tend to simply extend the schema at any whim. For a project with such far reaching implications as > D. It does not require complex code, it requires well designed tools. In > a XML based init world, you would need chkconfig and other tools. XML > authoring should be done only by the package maintainers. The rest > should be doable by external tools which share a common API. Basic UNIX Philosophy: All configuration is in plain-text; all you need is a plain text editor to configure anything. I use vi/vim for almost all my text editing (Kdevelop & kate for some of my programming stuff), but someone should be able to whip out joe or pico/nano or (gasp!) notepad over SMB and be able to easily This is not always 100% true (mostly commercial apps, like an RDBMS). You might say XML is plain-text...well, I would say that XML is text, but not plain. Look at some of the other respondents comments in this thread; XML is not easy. It CAN be but almost never is. > XML could help major projects such as the directory server bypass the > limitations of the current sysvinit. Check the problems with the > currently proposed init scripts in the fedora-ds wiki. I haven't had time to look at any of that, yet. If I find some spare time laying around, I will. Until then, I can not intelligently comment. Of course, I could just unintelligently comment now, but I'm not sure how to blow raspberries in email (just kidding). > I've included in this email a demo of a service configuration file for > Sun SMF. Don't worry, it's not CDDL-ed. You are not contaminated if you > read this. Funny that you included this example. Though I have not yet had any direct experience with this, you are the first person (outside of Sun) from whom I have read anything positive about this. It seems clear that the vast majority (of the email vocal component, of course) of the UNIX/Linux sys-admin world thinks Sun *way* screwed this up. > The interesting stuff this file brings: > 1) Internationalize the service descriptions (the xml:lang attribute is > a dream for i18n in this case). > 2) Include information about the documentation. > 3) Include dependency information. > 4) Include the start-up and shutdown commands. We can accomplish all of this already today without XML. > There are a lot of other things that can be done using this XML file. > These are just a few of the ones that I consider important. I've added > gEdit style syntax color in the HTML version ;-). To sum up my viewpoint: XML is appropriate, but not necessarily the best choice, when the data to be encoded naturally falls into a tree structure. There are other "corner" cases where XML could also be appropriate. The perceived and real complexities in editing XML without breaking stuff would be enough to put sys-admins off over it. Although any new-way-of-doing-things will cause growing pains as everybody learns the new way, in this case the negative effects are going to be amplified to everyone who uses FC & RHEL. A SysV Init replacement is not an appropriate application for XML...outside of dependency relationships, there is nothing that is even close to a tree structure. Also, it would be very difficult with XML to represent some of the odd dependency relationships; see the Apache & Tomcat example earlier in this thread, for one. IMHO, XML would be a big mistake in this instance. Whatever system we do come up with should use plain text, shell scripts and have tools like chkconfig ported to "just work". Here's a really simple idea: change the rc?.d/S## & K## numbers to all be the same for those things that can be started or stopped in parallel (so all the S11* 's go together) and have an init or rc (even better) that can decide about dependencies amongst all the "S11*" services by looking at the LSB info in the SysV Init scripts. Yeah, I know not the best way to represent the dependencies, but this solution has the advantage of only needing to modify either rc or init a little bit and still being "LSB compliant". Go ahead; shoot holes in this idea, it's just off-the-cuff anyway. -- Lamont R. Peterson <lamont@xxxxxxxxxxxx> Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
Attachment:
pgpb3TGykVdOB.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
