Date: Mon, 26 Mar 2001 23:41:29 -0800 From: Jordan Hubbard <jkh@osd.bsdi.com> To: Cy.Schubert@uumail.gov.bc.ca Cc: jar@integratus.com, areilly@bigpond.net.au, jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML? Message-ID: <20010326234129J.jkh@osd.bsdi.com> In-Reply-To: <200103270707.f2R77SR08693@cwsys.cwsent.com> References: <3AC007FF.1D9F60A3@integratus.com> <200103270707.f2R77SR08693@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think the point which has been emerging from this discussion is that
one can't really win in this game.
In scenario A, you have an /etc/foo.conf and all the Unix die-hards
("That's *always* been in /etc/foo.conf!") and heterogeneous
environment folks ("I have 437 different Unix variants here and 391 of
them use /etc/foo.conf") are happy. Everyone else, who wonder just
why the heck it's called /etc/foo.conf and why the heck its syntax
looks like some bad late-70's ASCII terminal control character set
(answer: "It is!"), is unhappy.
In scenario B, you have /var/db/localhost/config.pgsql with an
complete documentation set for interface programmers and set of access
utilities for everyone else which totally front-ends the configuration
process so that Joe User doesn't even have to know where the data is
kept or what format it's in. All the non-Unix and not-so-techy people
are happy. The Unix die-hards and heterogeneous folks are hunched over
a toilet bowl being explosively sick and screaming for their Solaris
or SCO installation media.
In scenario C, you have the abstract configuration database AND you
have /etc/foo.conf with some sort of fancy two-way auto-merging
thingamajiggy which propagates any change made from one data
representation to the other. The joe users are still happy because
they can use the configuration database thingy, though they still
sometimes stumble over /etc/foo.conf and wonder just why the heck it's
there. The Unix die-hards, on the other hand, are highly skeptical
about viability of this whole thing and proceed to prove their point
by getting themselves wrapped around the axle numerous times while
attempting to use both interfaces at once or getting into odd race
conditions between the two interfaces. Between that and occasionally
managing to turn their systems to spam by having the wrong edit
back-propagate to the correct copy, well, pretty soon they're calling
your scenario C solution a grossly over-engineered and highly
dysfunctional hack. "Bring back scenario A!", they will cry.
To put it somewhat more succinctly, I think we're all pretty wedded to
our ways and only accept change when it's a significant order of
magnitude improvement beyond what we currently have or it doesn't
conflict with any existing scenario. Thus Unix slowly accretes
functionality to itself without changing shape too much. :)
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010326234129J.jkh>