Re: A standard package for config files is needed

[Stephen Leake <stephen_leake@acm.org>]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> Sounds like a good idea, but why all the sound and fury?  

Well, I don't think this discussion counts as "sound and fury" :). It
started with "anybody have a good config file package".

> This is what the IFF (Interchange File Format) was designed to do.
> Requiring simple programs to understand ALL IFF types would indeed
> be a heavy burden. 

I guess that's similar to picking XML as the Config File format, but
only using a subset.

> But IFF is designed so that data in formats your program doesn't
> understand can be skipped over. One nice thing about .iff files is
> that if you really have to, you can go in with a hex editor and muck
> about to fix a broken file, but reading or writing an IFF file as a
> byte or 16-bit word stream is fairly painless.

Well, if there is no subset of IFF that is easily edited in "any old
text editor", then we can't use it; that's a prime requirement.

> <snip more description>

It sounds like IFF is "merely" a top-layer grouping format; the
details of any particular object are specified elsewhere. So we'd have
the first four bytes be "CONF" (or "TEXT"), and IFF would have nothing
to say about the rest of the file. Not much help.

> How does this differ from XML?  XML formatting is more about schemas,
> and is entirely text based.  In IFF files, 'TEXT' is just another file
> format.  With IFF files you can support all of the UTFx file formats
> in the Unicode (and ISO 10646) standards without raising a sweat.

Well, somebody has to implement it! Is there an Open Source/Free
Software implementation somewhere?

> So IMHO, the way to go is to provide an IFF reader/writer package,
> have it support an 'XML ' data type, and go from there. Those people
> who only need text support, and don't care about localization can
> use XML. Those who need the whole ball of wax can create IFF files,
> and support XML as a subset. 

If XML is a subset, this is way more power than we need.

> (I believe that Electonic Arts is still maintaining the IFF
> standard, but the original can be found here:
> http://www.concentric.net/~Bradds/iff.html)

The document mentions some "public domain" C source code, but I don't
see them on the web site.

-- 
-- Stephe