haitex@pnet01.cts.com (Wade Bickel) (09/15/88)
[for the mithical line-eater (is there really such a thing?)]
Having had to get into EA's IFF code this summer, I've been more
than a little disappointed. The code is cumbersome and hard to work with.
So, I started working on a re-vamp. Recently I spoke with Stu
Furgeson and discovered that I had minor misconception as to how the
format was defined. In particular, the form specifier (such as ILBM) is not
a chunk. This makes my elegant solution to the whole problem un-workable,
requiring a much less generic parser design.
So the question I wish to pose is; Would you (the Amiga community)
reject a re-design of the current IFF standard?
In order to maintain compatablility, I figure all current formats
would have to be supported by any forthcomming library, to allow old programs
to be functional.
I realize this would not be a completely painless change, but the
current definition is flawed and if we don't do something about it, it must
die eventually. I'd hate to see some other machine support a different IFF
standard which is clearly superior, and thus hurt the Amiga, which is still
clinging to a flawed standard in the belief that any standard is better than
none.
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.rap@ardent.UUCP (Rob Peck) (09/16/88)
In article <3427@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) writes: > Having had to get into EA's IFF code this summer, I've been more > than a little disappointed. The code is cumbersome and hard to work with. > So, I started working on a re-vamp... > [more details deleted] There is an alternative to EA's code... a fella named Jim Kent (of Aegis Animator fame, I believe) who did a rehash of the EA code in a far more understandable fashion and (I believe) placed it in the public domain. The name of the program group in general is "JIFF". Lattice was sufficiently impressed with its (relative) simplicity that it is now on the Lattice 4.0 disks as source code. Perhaps John Toebes can comment on the PD status or if Jim is listening, he can confirm? I have a copy of the code and I thought that it was once submitted to Fred Fish for possible inclusion in the usual way, but I don't keep a CAT-FISH list handy so I cannot look it up. When last I talked to Jim, he had taken care of all of the data compression stuff and he said that JIFF now included a fully EA compatible IFF reader and writer program. Posted in the hopes of preventing reinventing the wheel and letting Wade get on to the more important things in life, like creating real (money-making?) software for Amy. Rob Peck
papa@pollux.usc.edu (Marco Papa) (09/16/88)
In article <3427@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >[for the mithical line-eater (is there really such a thing?)] > So the question I wish to pose is; Would you (the Amiga community) >reject a re-design of the current IFF standard? Yep. I would. > In order to maintain compatablility, I figure all current formats >would have to be supported by any forthcomming library, to allow old programs >to be functional. > > I realize this would not be a completely painless change, but the >current definition is flawed and if we don't do something about it, it must >die eventually. I'd hate to see some other machine support a different IFF >standard which is clearly superior, and thus hurt the Amiga, which is still >clinging to a flawed standard in the belief that any standard is better than >none. So far I haven't seen anything that can't be done with the current standard and its "extension" features. Show an example of such a case. The claims "if we don't do something about it, it would die" and "some other machine ..." are clearly unsubtantiated, and do nothing to make me change my opinion. Note also that one of the Working Groups set up at DevCon is involved in movin the "current" standard to a loadable/sharable library. If you do thing on your own, without CBM's blessing you are simply bound to failure. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/17/88)
In article <3427@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes:
->[for the mithical line-eater (is there really such a thing?)]
--No it was fixed in all US sites by 1985--
-> Having had to get into EA's IFF code this summer, I've been more
->than a little disappointed. The code is cumbersome and hard to work with.
True.
-> So, I started working on a re-vamp. Recently I spoke with Stu
->Furgeson and discovered that I had minor misconception as to how the
->format was defined. In particular, the form specifier (such as ILBM) is not
->a chunk. This makes my elegant solution to the whole problem un-workable,
->requiring a much less generic parser design.
First what was your misunderstanding? IFF can be parsed fairly readily by
most "types" of parsers primarily because it's grammar is self consistent.
-> So the question I wish to pose is; Would you (the Amiga community)
->reject a re-design of the current IFF standard?
Yes if you decided to redesign it simply because you blew it while reading
the documents. Please, don't be offended but there are already "other"
standards that are competing with IFF and you should really check out one
of those first before making a subtly different IFF. (GIF and TIFF come to
mind)
-> I realize this would not be a completely painless change, but the
->current definition is flawed and if we don't do something about it, it must
->die eventually. I'd hate to see some other machine support a different IFF
->standard which is clearly superior, and thus hurt the Amiga, which is still
->clinging to a flawed standard in the belief that any standard is better than
->none.
Please, let us know what the "flaw" is first and *then* ask us if we want
to change it.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.jms (joe smith) (09/17/88)
I don't understand your posting. IFF compares favorable to X.409, is much better than GIF (by having self identifying sections), and is self consistent as documented. What in particular bothers you? The fact that the top level descriptors are 12 bytes instead of 8? This is not a flaw. To do it any other way would invalidate the concept for "FORM", "LIST", "CAT". > I realize this would not be a completely painless change, but the > current definition is flawed and if we don't do something about it, it must > die eventually. I'd hate to see some other machine support a different IFF > standard which is clearly superior, and thus hurt the Amiga, which is still > clinging to a flawed standard in the belief that any standard is better than > none. First you need to prove that the current standard really is inferior (and not merely just difficult for novice programmers) and then you need to demonstrate your new proposed standard - not just say "it should be changed". If the question is "will we accept a major and unnecessary change to IFF so that one person's elegant hack will work", my vote is a resounding NO. +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 "POPJ P," UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
peter@sugar.uu.net (Peter da Silva) (09/17/88)
I am quite satisfied with the design of IFF, thank you, and I don't see how a new (and eventually incompatible) standard can help. Certainly I don't see how making it into a chain of chunks (as you seem to want) can help... a tree is much more powerful. Now I do agree that the sample IFF code is a lot more complex than it needs to be. A cleaner version of that would help immensely. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/18/88)
In article <584@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes: >In article <3427@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) writes: >> Having had to get into EA's IFF code this summer, I've been more >> than a little disappointed. The code is cumbersome and hard to work with. >> So, I started working on a re-vamp... >> [more details deleted] > >There is an alternative to EA's code... a fella named Jim Kent >(of Aegis Animator fame, I believe) who did a rehash of the EA >code in a far more understandable fashion and (I believe) placed it in the >public domain. The name of the program group in general is "JIFF". Jim Kent's code, while infinitely more readable, is still not an optimal solution. Error handling is a b*tch, and the code is designed to work only with FORM ILBM's; translation to 8SVX or SMUS is non-obvious. There is, however, an even better alternative (I think). #define SOAP_BOX_MODE Stuart Ferguson and I have been working on some IFF parsing code (that is to say, Stu's been writing it, and I've been nodding my head). Believe it or not, it makes dealing with IFF files *easy*. It reads and writes to all filesystem devices (PIPE: included), as well as the clipboard. We don't use EA's method or interface for scanning files; we do it in a way such that control is maintained at top-level as much as possible. You can use the library to scan for chunks yourself, or you can let the library do it for you. The library also correctly maintains the various context levels and property scopes, so you don't have to. You can read an ILBM inside a LIST VDEO as easily as you can out of a FORM ILBM. It's all utterly painless. We think it's Zen. We're trying to get together with some AmiGuys to discuss some periphery issues. We hope to have it available Real Soon Now (I won't give a specific date, since it's a middle-burner project for both of us). Rest assured that it *will* see the light of day in one form or another. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
haitex@pnet01.cts.com (Wade Bickel) (09/18/88)
rap@ardent.UUCP (Rob Peck) writes: [discussion of JIFF, deleted. Subject is my suggestion to re-do IFF.] >Posted in the hopes of preventing reinventing the wheel and letting >Wade get on to the more important things in life, like creating real >(money-making?) software for Amy. > So far I have only spec'd the thing. The purpose is to allow more flexability in the reading of complex data. The nice thing about the method I've come up with is that it is very simple and straitforward. The actual writer code (not including the low level io stuff, such as WriteBytes) is only about 10 lines of code. The support routines (used to locate the data to be written and specify what kind of chunks it should be stored in) take up perhaps another 100 lines, max. The reader is a bit more complicated, but would make things like ANIMS, or ANIMS where multiple paths (for Laser Disk like applications) reasonable undertakings. As far as getting on with creating "real" software, that's what I AM doing. Otherwise I'd spend a month writing this code, and just present it. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM Opionions expressed are mine, and not necessarily those of my employer.
karl@sugar.uu.net (Karl Lehenbauer) (09/21/88)
People looking for alternative code to read and write IFF files are directed to my IFF CAT archiver that was recently published in comp.sources.amiga. It's a rewrite from the original EA code, but I think it's pretty good, and moderately commented. It does a bit more work than it needs to, insuring that the sums of the lengths of the chunks within FORMs, LISTs and CATs match the length of their parent chunk, but the IFF spec requests that this be done and it's probably a good idea for an archiver, eh? -- -- uunet!sugar!karl, Unix BBS (713) 438-5018
mp1u+@andrew.cmu.edu (Michael Portuesi) (09/29/88)
> *Excerpts from ext.nn.comp.sys.amiga.tech: 17-Sep-88 Re: How satisfied are* > *you w.. Peter da Silva@sugar.uu. (474)* > Now I do agree that the sample IFF code is a lot more complex than it needs > to be. A cleaner version of that would help immensely. A better solution (which someone else mentioned is being worked upon) is to make the IFF code into a dynamic library so we don't even have to look at it in the first place. Of course, a set of clean IFF code would help a lot with those who want to understand how IFF works. Perhaps the IFF library source code will be made public? How will the iff.library be revised to handle new IFF codes? The Andrew Toolkit environment is extensible by making each new piece of code its own dynamically loadable object. It is possible to extend the system merely by writing a new code object and dumping it in a system directory -- nothing needs to be recompiled. If one basic iff.library were created, containing a general IFF parser, and subsequent separate libraries for ILBM, 8SVX, SMUS, ANIM etc were created, it would be possible to add new IFF formats merely by writing a new library containing routines to handle that format and installing it. None of the other IFF libraries would have to be removed or changed, and it would be possible for Amiga owners to quickly update their system software without waiting for a new release of one monolithic library that handles a batch of new formats. Is someone on the IFF Working Group reading this newsgroup? Could someone forward this suggestion to them? --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "my friends say she's a dumb blonde, but they don't know she dyes her hair"
ewhac@well.UUCP (Leo L. Schwab) (09/30/88)
In article <8XEH6zy00VsfM3KmIu@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes:
:Of course, a set of clean IFF code would help a lot with those who want to
:understand how IFF works. Perhaps the IFF library source code will be made
:public?
:
Personally, I think a lucid programmer interface to a parser will go
a lot farther than staring at the parser's innards. Even though our parser
is relatively small and extremely concise, I still get lost looking at Stu's
code.
:If one basic iff.library were created, containing a general
:IFF parser, and subsequent separate libraries for ILBM, 8SVX, SMUS, ANIM etc
:were created, it would be possible to add new IFF formats merely by writing a
:new library containing routines to handle that format and installing it. None
:of the other IFF libraries would have to be removed or changed, and it would be
:possible for Amiga owners to quickly update their system software without
:waiting for a new release of one monolithic library that handles a batch of new
:formats.
:
This is exactly how we're doing it, for precisely the reasons you
gave.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor