Re: configuration files

[James Frazer <jfrazer@xxxxxxxx>]

I agree -- XML should not be used for the files in /etc/rc.d  ... That's 
 a bad idea -- but I don't really think those can be classified as 
configuration files -- as they are control scripts, right?

I'm not entirely sure how rc.d got into all of this.

Commenting on *nix configuration files in general I think it's safe to 
say that there's lots of unnecessary diversity.  For example -- some 
configuration files are very specific with key/value pairs.

var=somevalue

Where as other files -- such as /etc/passwd use an implied system where 
the key/value (so to speak) connection depends upon which field/column 
the data is in (and the key is not even stated).

And there are many other forms of syntax.  In /etc/passwd the fields are 
seperated by colons.  In /etc/fstab the fields are seperated by 
whitespace.  /etc/gettytab uses termcap (I think).

In some configuration files multiple values are seperated by whitespace, 
in others they are seperated by commas, etc, etc.

So if someone was ever to write an admin-frontend to any of these 
configuration files (where relevant) they would have one heck of a time 
sorting things out.  And it seems as though every config file differs 
slightly from the next in some small way.  Of course we can say many of 
these files don't need a frontend (as they probably don't), but can 
anyone see what I'm getting at here?  Even just editing files by hand 
I've always been somewhat annoyed that everything is done differently -- 
often when it seems as though there was no foreseable need to be 
different in the first place.  But I suppose until I code something 
better I should probably shutup.  ;-)


--James




Matthew Dillon wrote:

>     I think, ultimately, what matters is how things improve from
>     a sysop's functionality and ease-of-use perspective.  It's all well
>     and fine to talk about the capabilities of XML, but there's no point
>     if the capabilities aren't useful for the particular real-world task
>     being contemplated (or, more to the point, more useful then what we
>     could get out of RCNG's existing capabilities).
>
>     RCNG is a great example of this.  RCNG already had the ability
>     to 'start' and 'stop' subsystems, and RCNG already contains all
>     the dependancy information required to deal with dependant subsytems.
>     But how many people do you know actually go to the trouble of CD'ing
>     into /etc/rc.d and running ./blah start and ./blah stop on a regular
>     basis?
>
>     Even though it is not difficult to do the above, from an ease of
>     use perspective there is a huge difference between doing the above
>     and doing, say, a one-line 'rcstart subsystem_name' command as root.
>
>     But in less then a day I was able to make significant improvements
>     to the use of the meta-information embedded in the RCNG scripts
>     which enables rcstart/rcstop (and future work) to take advantage of
>     it in a manner that presents a simple, straightforward, 'easy to use' 
>     interface to the user/sysop.
>
>     XML would not make any of this work any easier.  No matter what form
>     the data is in, you still have to process it in a manner that benefits
>     the target function.  In the case of RC stuff that means dealing with
>     fairly complex dependancy graphs.  In fact, XML would make the work
>     a whole lot harder.  I wonder how many of you have actually *LOOKED*
>     at the files in /etc/rc.d ... some of those scripts do rather complex
>     things that really can only be done in a shell script.  XML would only
>     add unnecessary layers of complexity and not actually allow us to 
>     remove any of the existing complexity.  Another example:  half the RCNG
>     scripts do not support 'stop'.  Reimplementing in XML would not magically
>     cause 'stop' to be supported.  In otherwords, you still have to do the
>     work required to implement the 'stop' function for those subsystems that
>     do not have it.
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>