> Perhaps this is a good time I should mention that I think sqlite would
> also be good for the password and login databases? :)
Someone has already pointed out the horror that is the Windows
registry. IIUC, even MS has figured out this is a bad idea, and gotten
away from it with Vista. But it's been tried on Unix systems before as
well. People who've dealt with AIX tend to feel the same way about
it's config system as they do about the Windows Registry.
Having a magic tool to edit these files is a pain - it means you now
have two sets of things to learn: the magic tool, and the specific
details of the file you're dealing with. On a Unix system, knowing how
to tweak text files is pretty much a given. So all you need is the
details for that file.
Using a binary format brings it's own problems. How hard is it to fix
a corrupt database? How hard is it to figure out that the database is
so corrupt you aren't going to get anything out of it, so you might as
well give up? How robust is it - can a corrupt block fry the entire
database? How about portability - can I move the file to a completely
different architecture and still get the data from it? If any of these
are noticably worse than they are for text files, changing is probably
not a good idea.
Someone else mentioned XML. Well, it's easy to parse - assuming you
read that as "someone else wrote the parser for us". That's true for
lots of things. I also question the sanity of using it. But I wind up
doing a lot of it, because my clients like the buzzword compliance. I
regularly beat on them to take advantage of what XML can do that other
formats can't. Meaning I make them install validation software, and
pay me to write schemas for them, and get them to add hooks to the
repository so you can't check in xml files that don't validate. But if
you're not going to do that kind of thing, the major feature XML
brings is the buzzword compliance.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
