From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,47bc849aad30d586 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-02 18:04:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!cox.net!news-east.rr.com!chnws02.ne.ipsvc.net!cyclone.ne.ipsvc.net!24.128.8.70!typhoon.ne.ipsvc.net.POSTED!not-for-mail Message-ID: <3CFAC0AD.8040504@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A standard package for config files is needed References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 03 Jun 2002 01:00:02 GMT NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: typhoon.ne.ipsvc.net 1023066002 24.61.239.24 (Sun, 02 Jun 2002 21:00:02 EDT) NNTP-Posting-Date: Sun, 02 Jun 2002 21:00:02 EDT Xref: archiver1.google.com comp.lang.ada:25230 Date: 2002-06-03T01:00:02+00:00 List-Id: 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)