XML and configuration files [ was Re: Howto upgrade RPM ]

[Michael]

> How does forcing a change to XML in configuration files translate to
> moving forward.  I'm sorry, but configuration files are a neccessary
> evil in many cases, but they in no way drive where anything is going.

A unified configuration structure makes it easier for programmers. It has
absolutely nothing to do with those of us who like editing config files by
hand. There isn't even any reason that you need to change the original
config files format from that which it already is. You can just create an
interface that lets application programmers have an easier job working
with config files and spares us having many semi-compatible programs that
have to update every time the config file format is slightly changed.

> JOE: Hey Jack, check out this new config file.
> JACK:  Wow with that config file I can develop the next killer app.
> 
> The above is the impression I get from the pro XMLizing configs group,
> and it is ludicrous to assume that this could get us anywhere.  The only
> thing it would do is make a few people feel more comfortable with the
> fact that all thier config files look allike. 

It'd greatly help with configuring multiple services on one or more
machines from a common interface. It'd be a great boon to desktop and
enterprise users as it'd allow programmers to concentrate on
user-interfaces and not on trying to work the bugs out of parsers for 50
different services.

> Hey I've got an idea, why don't we unify all of our configurations into
> a single xml file, and then store that file in a DB for faster access,
> and voila` we have a "registry"

Why on earth would you want to do that? It makes more sense to have a
virtualized abstraction layer. That way to applications it looks like
there is something very much like a registry but you can still edit the
config files with your usual tools and everything is backward comaptible.

> I think discussion of these ideas are good, but end result is little or
> no gain in this case.  What will drive forward comuting et al is
> inovation.  Inovation will not be created by XML, but XML may be the
> tools that is used to achieve the next inovation.  That no one knows.

This isn't really meant to drive forward computing. It's made to unify
it. It's not a sexy thing to do but it makes it much easier for everyone
else to write their sexy apps that do drive us forward. It's like getting
a translator that knows every language in the valley that will translate
for every one. You COULD tell everyone to learn to share one common
language but obviously that isn't going to happen or you COULD tell
everyone to learn all the other languages but that isn't a very good
solution either. Telling everyone they can use their own language and
we'll translate into the universal language for them and if needed back
into their own language is much more user friendly.

> I believe that by inserting a parser to handle XML, and then still
> having to hadnle the values may very well increase the complexity of the
> most basic function of an application, loading itself to do work.
> Eventually the application is going to have to deal with the values
> itself, and whether it comes from formatted text, or an XML parser that
> data will ultimately look the same to it.  I have yet to see a valid
> reason why XML could help the situation.

The application wouldn't even need to notice. For that matter the
application could toss it's own parser if it wanted to and be like
everyone else and only worry about the parsed representation. It all
depends on which was easier for the programs author.

I've written a lot of parsers and it's a pain. Unless you have a very
special situation or your a total numb nut you don't even know what the
config file looks like inside your application. You only worry about the
options it passed to you.

> If a unified configuration tool is the goal, then lets steal a concept
> from apple that has been stolen by others, and create a control panel,
> that authors of the different packages can create confiuration tools
> that will be placed in the control panel on install. Then there is one
> place to go for all configurations that conform to that most basic
> standard, yet the author still has total and complete control over how
> they want get configuration data into thier application.

You are missing the entire point. There are lots of half-shit kicks at a
unified control panel in Linux and none of them are very useful. The
control panels authors have to worry about parsing in and out of 50
different config file formats. Each one wastes space and creates bugs and
requires someones special attention to do. By having an XML-translation
layer a single person could author a complete control panel, reduce bugs,
and have time to innovate on making the interface more friendly. And you
wouldn't have 3 implementations of each parser on your computer to be
broken in different ways just because you have both Yast and Linuxconf on
your computer along with the original apps.