Re: Caldera installation - something Debian should learn
> 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.
i assume that anything you propose and/or write would be free software, yes?
if it's free, there is no way to prevent other parsers for the same
format being written; it's a fact of life that sometimes people want to redo
an old algorithm. so this "problem" (which is actually a good thing) is not
related to using an easier-to-write-and-parse format.
> 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).
if i can't tell exactly what it's doing, it's too obscure for me. further,
libc is pretty solid because it's both old and used by every c program
running under unix. no bug could survive long in such an environment. by
contrast, the first time a new binary format is introduced, the reference
implementation is guaranteed to be pretty buggy, unless you've designed some
new self-debugging programming language, in which case i'd rather see you
release that first. ;)
> Counter example: sendmail.cf
>
> If parsing this is easy to do please write one in the next few hours
> and post it. :>
please see www.sendmail.org for an excellent implementation of a sendmail.cf
style configfile parsing program. that's my point, really... if you use a
form that has already been used for a config file the work involved in
parsing it is nil.
> 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.
how does one common api preclude using a good format? if your text file
parsing api is good, nobody will ever write another one to do the same task.
if it's a good api for a text file format, not only will it be easy to
parse, but i can edit my config files with sed, which means you don't have
to write an equivalent for your database. now that's saving effort.
> 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
why can you store a checksum on a binary database but not a text file? and
even better for checking whether something has changed than a checksum is to
check the modification time -- another case of "already been done in an
easier way".
> situation where a text file is better in speed or space than a db.
true, but speed and space just aren't an issue (as you mention in a later
post to this list) for config files.
> What about differential backups?
umm... you got me... what about them? (please clarify how this is relevant
in the context of this thread, i don't see what you're getting at.)
> Who said you cannot dump the database to a text file?
well this would be nice, but it's still wasted effort to parse the database,
and you introduce problems of synchronization and security (who gets to edit
the httpd configuration? the sendmail configuration? how do you make sure
the web admin doesn't get to fubar the password database?)
--phouchg
"For a price I'd do about anything, except pull the trigger: for that I'd
need a pretty good cause" -- Queensryche, "Revolution Calling"
PGP 5.0 key (0xE024447449) at http://cif.rochester.edu/~jpt/pubkey.txt
Please do not Cc: mailing list replies to me.
Reply to: