init: API

[Lamont R. Peterson]

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 at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20051118/19e56a9a/attachment-0002.bin