Re: Why not XML based configurationfiles?

From: Christopher Browne (cbbrowne_at_acm.org)
Date: 07/05/04 

Date: 5 Jul 2004 02:46:56 GMT

The world rejoiced as Nick Landsberg <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote:
> Christopher Browne wrote:
>
> Not really a followup to Chistopher's latest comment,
> but general remarks about this whole thread -
>
>
> My thoughts regarding this whole discussion regarding
> config file formats (esp. wrt. Linux) -
>
> 1 - There is no "big brother" in the Linux world which mandates any
> particular format of config file. Apps are written by different
> developers and development oranizations.

Agreed.

I would go further and suggest that, in this context, "Linux" is
merely the name of an operating system kernel, whose configuration
file is typically found in /usr/src/linux/.config

NONE of the other stuff is "Linux software:"

 - Apache even runs on Windows;

 - MTAs are generally quite portable across Unix flavours, if not
   Windows;

 - GNOME and KDE are _NOT_ specific to Linux, but run across numerous
   flavours of Unix;

 - Even the "Linux packaging tools," rpm and dpkg, are NOT "for Linux"
   because they are getting observed increasingly often on platforms
   that are conspicuously NOT LINUX. For instance, AIX version 5
   uses rpm to install additional software.

Many applications that are commonly run on Linux are developed by
people whose first priority goes to _Other Platforms_; some would-be
"Linux solution" means nothing to them when they don't necessarily
even support Linux.

> 2 - Trying to impose a standard externally will not work unless
> there is *market pressure* or standardized OS "support" (and we've
> all seen what happens with the Windoze registry). So far, the only
> arguments I've seen for a standard format have been for the
> sake of convenience of the administrators. In most corporate
> hierarchies, administrators are considered lower than Whale***
> so there is not likely to be any market pressure from corporate
> higher-ups to help them out. When given a choice of buying
> product ABC which may be hard to configure and product
> XYZ which my be easier to configure but costs twice as much,
> which one do you think corporate higher-ups will choose?
> I can just hear the conversation:
> Administrator: "But boss, it's hard to adminster!"
> Boss: "Stop whining and go do the job I hired you to do!"

The other possibility is to pooh-pooh the "commercial administrators"
part, and to say:

 "But we need this stuff so that Granny can run Linux on her
  computer."

This is, of course, an even less useful idea, because "ignorant
end-users" are, if anything _less_ able to assert legitimate design
requirements than the upper level managers that get their modicum of
cluelessness from reading InfoWeek.

> 3 - If, by some chance, a whole bunch of software vendors got
> together and thought it might be a good idea to standardize the
> config files, what would happen? My cloudy crystal ball says that
> someone would suggest forming a "standards committee" with
> representation from the major software vendors for that platform.
> This committee would meet every once in a while, or exchange Emails
> every once in a while and might come up with a standard (which
> nobody really likes but are resigned to) in maybe 2 years at the
> earliest, after they had debated how many angels might dance on the
> head of a pin. And (gasp), they might reinvent the registry. (In
> case you didn't notice, standards bodies are political, not
> technical. You are not likely to get a good technical solution out
> of one. You are likely to get the solution favored by the
> corporation with the most "clout.")

This is largely what happened with LSB. LSB defined a set of
requirements for building a system on which one could install
LSB-compliant applications.

But nobody much cares, because it's a pretty worthless
lowest-common-denominator. A distribution maker can't win big
contracts by building something that's generic; they "win big" when
they provide a system that is a lot _more_ functional than the LCD.

> 4 - Even if such a standard were published, what would be the
> *monetary incentive* for the software developers to change what they
> already have (and which works) to comply with this new standard?
> (This is a rehash of point 2 to a large extent).

Here, I disagree. The point isn't that of *monetary incentive*.

It is of convincing developers that it is such a good idea that they
should throw away what works now, require that everyone reimplement
all their configuration schemes, and replace it with the New Thing.

If the replacement "New Thing" is really conspicuously better than the
Old Thing, money isn't necessarily required as incentive.

What really *is* required is incentive for the massive amount of work
both at the project level, as well as on the part of every user of the
system that gets forced to put effort into the upgrade.

If it's trivial to write a tool to rewrite config files, then the
effort might not be too immense.

But for someone with (say) a particularly complicated MTA
configuration, there may not be enough staff around to do the upgrade,
and multiply that by thousands of users, and you get a big hue and cry
that says: "Don't you dare to ******** touch the configuration
scheme!"

The problem is that cost of the "upgrade" isn't a burden on the
developers, but rather the existing user base.

> 5 - How often do the config files change once you've got them right
> the first time? The *format* of the file is less important than
> understanding what the parameters mean and this is different for
> every application. Should we standardize the nomenclature in the
> config files? (I can see yet another standards body for that!
> GACK.) No formatting scheme is going to help you when one of the
> parameters you must set is named "YX24AB", thus

I haven't yet properly grokked what Apache config files _really_ mean,
as far as semantics are concerned, so that's always somewhat magic to
me.

When the problems are semantic, changing the grammar a bit isn't
terribly helpful.

> Bottom Line: This spit comes with the territory. If you can make a
> financial case for changing the way it is, you may stand a chance.
> If you can't, I would rather bet $5.00 on the snowball in hell.

Remember that the costs are distributed... There are costs at the
"software project" level, but also at the _users'_ level. Those that
have considerable infrastructure devoted to the current approach would
be seriously disrupted [e.g. - incur SUBSTANTIAL costs] if changes
were made.

> P.S. - Think about this. If you *can* make a financial case for it,
> and let's say you now have two (2) admnistrators supporting X users.
> Will your company now need only one (1) ? Could the one they fire
> be you?

This is what caused me amusement in the last round of "Microsoft
savings" commercials. The only way I can see the upgrades saving
companies millions of dollars is if it allows them to lay off a whole
bunch of administrators, thereby throwing a bunch of MCSE's onto the
unemployment lines. 

-- 
select 'cbbrowne' || '@' || 'ntlug.org';
http://cbbrowne.com/info/emacs.html
Rules of the  Evil Overlord #94. "When arresting  prisoners, my guards
will  not allow  them to  stop and  grab a  useless trinket  of purely
sentimental value." <http://www.eviloverlord.com/>