RE: Caldera installation - something Debian should learn
The one advantage I've seen to storing data as text rather than as a
proprietary data set accessible through 1 API is the issue of how to deal
with the data when it gets corrupted.
When data gets corrupted, and it is in text format, there is somehow a
confidence level because you can actually see where the corruption has
occured and go on with trying to correct it.
If the data is in a proprietary format, just about the best means for
restoration is backup - which usually means a loss of data dependant on the
time delta.
Ironically, the best example I've had to deal with to demonstrate this is to
compare two different email systems: sendmail and Microsoft's Exchange.
Exchange is proprietary, whereas sendmail has it's data stored as text.
I have never had an Exchange server up which did not at some point suffer
data corruption. And try my best to correct the issues with thier recovery
tools, almost always I've had to end up doing a backup recovery.
Sendmail, while a pain-in-the-ass to setup (especially compared to
Exchange), 1) has much fewer times when the system goes down or the data
gets corrupted, 2) when data corruption has occured, I've been able to
restore the email with minimal loss (usually affecting just one or two
people) because of the fact everthing was stored as text.
-----Original Message-----
From: R Garth Wood [mailto:rgwood@peace.netnation.com]
Sent: Thursday, April 22, 1999 5:54 PM
To: Jonathan P Tomer
Subject: Re: Caldera installation - something Debian should learn
On Thu, 22 Apr 1999, Jonathan P Tomer wrote:
> > I have read it. Keeping data in a text file that needs to be parsed
> > is an antiquated notion that needs to be eliminated. The information
> > contructs are correct, however.
>
> no no no! keeping data in a text file may be an old notion, but is not
> antiquated and *definitely* does not need to be eliminated. quite the
> contrary, in fact. text files for configuration information are Very Good
> Things (tm) because *text files can be edited however one wants*. forcing
In fact I believe that's their most glaring weakness. Enevitably popular
software has more and more parsers that read and write it's config files.
Note that they are DIFFERENT parsers(not equivalent ones). For any
dataset there should only be one way to access the data(one API for
example). This ensures that work is not duplicated. THIS is a good thing.
> the sysadmin to depend on a possibly buggy, definitely obscure admintool
is
I have never mentioned an obsure admintool. If there was only one API
it certianly would not be buggy(libc for example is pretty solid).
> always a bad thing. parsing a text file, otoh, is comparatively easy to
do,
Counter example: sendmail.cf
If parsing this is easy to do please write one in the next few hours
and post it. :>
> especially since it has been done already numerous times for just about
any
> kind of structure.
You see that's the problem. It would not have to be done numerous times
if there was one common API. Who many ppl on this list have wrote a
perl script to edit httpd.conf somehow. Wasted effort.
> binary databases, by contrast, have only one virtue: they are slightly
> faster to look at. this does not even begin to compare with the advantage
of
Slightly faster? No way. I store a checksum on a n MB file. You have
to parse the whole thing to see if it's changed. If fact there is no
situation where a text file is better in speed or space than a db.
What about differential backups?
> being able to edit the file. you can have some speed savings by building
an
Who said you cannot dump the database to a text file?
> index of the database to be used by the administration tool, but it's not
> really worth the effort imho.
Yes that would be silly.
+---------------------------------+-------------------------------------+
| R Garth Wood | Making waves... |
| Stormix Technologies Inc. | |
| rgwood@stormix.com | |
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: