Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: An IFF-based filesystem? Keywords: IFF Amigix FS Message-ID: Date: 23 Apr 89 06:16:34 GMT Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 54 I've got an idea to bounce off the net here... In considering design and implementation of a file system for Amigix, I have been contemplating the idea of designing a filesystem which is structurally similar to Unix, but which has library support for manipulating IFF files, and which actually uses IFF files for object files, executables and any other filesystem-specific formats. Part of the reasoning behind it is that the IFF format is far more flexible than the AmigaDOS load file format, as the fields can easily vary, and new ones can be added without affecting the performance of the loader, except for a slight speed penalty to skip irrelevant stuff. The idea would be to creae a new FORM, perhaps FORM CODE. Within this single IFF FORM, you could have all sorts of data related to a program. You could have the executable (FORM EXE, likely) and the object (FORM OBJ) along with the source (FORM SRC) and a man page (FORM MAN) and documentation (FORM DOC) and a Makefile (FORM MAKE) and a Workbench icon (FORM ICON) and other identifying things like the originating author, machine, etc. (as with LIST) It could even be extended so far as to have multiple versions of the source coordinated within the file, in a manner similar to SCCS under Unix. And all of this could be put in a single file, grouped together conveniently. Of course, there would be utilities for importing and exporting the components to/from separate IFF component files, or (in some cases, like a Makefile or documentation file) to/from a regular file. There could be a "man" command which first searches for the file described, and if found, searches it for a FORM MAN to print. Otherwise, it could search /usr/man, or just give up. An info command could simply describe as much as it can about what a given IFF file contains. You could even toss in things like an ILBM as a startup-screen which the loader could display, or whatever... the possibilities are vast. Now, what do people thing of this idea? Any ideas for improvements on this (first-draft-type) model? Also, how could it best be intergrated with Unix (V7) system calls transparently, yet usably? Also, where can I get the most recent IFF specifications? I am basing this on the EA IFF '85 specs given in Appendix B of the Addison-Wesley RKM's. If someone could Email me the most recent specs or direct me to them, I would appreciate it. I like the quote in the those specs: "Simple things should be simple, and complex things should be possible." Alan Kay, whoever that is. Maybe I'll toss it in my .signature... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.