Re: A standard package for config files is needed

["Robert I. Eachus" <rieachus@attbi.com>]

Preben Randhol wrote:

> On the GtkAda list there has been some discussion on making a standard
> package for reading/writing configuration files. As most programs need
> this it would be very nice with a small, platform independant, robust
> but easy to use package.
> 
> Of course one can use XML for something like this, but in most
> applications this would be an overkill. Besides a program shouldn't have to be
> tie in with XMLAda just because of the configuration files. This package
> should be nice for small applications made by student, hobbyists or
> professionals...
> I think this is a package that should be kept as simple as possible and
> easy to use and robust.


Sounds like a good idea, but why all the sound and fury?  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. 
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.

Basically the way an IFF file works is that every IFF file starts with a 
four byte header.  Almost all IFF files start with 'FORM', 'LIST', or 
'CAT '.  The next four bytes are an unsigned long that tells you the 
number of bytes in the entire object.  One of the two exceptions to the 
above is that some x86 specific IFF files start with 'RIFF' to indicate 
that the byte order of numbers is reversed from standard IFF. (Also some 
MIDI file generators leave out the initial 'FORM' and size and start 
with 'MThd'.)

Of course, the real power of IFF is that the structural types can 
contain a hierarchy of nested objects.  ILBMs are interleaved bit-maps 
for video, 8SVX, AIFF, etc. are audio formats. GIFF is a fairly well 
known image format with a table of 256 colors, etc.  Since the size of 
the object, including nested objects always follows the type, a program 
can skip the data types it doesn't recognize--or want to deal with--and 
select out the data that it does.

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.

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.  (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)