Xref: utzoo comp.sys.mac.apps:4775 comp.sys.mac.misc:9874 comp.sys.mac.programmer:22865 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!mit-eddie!snorkelwacker.mit.edu!bloom-picayune.mit.edu!18.70.0.226!lfk From: lfk@eastman1.mit.edu (Lee F. Kolakowski) Newsgroups: comp.sys.mac.apps,comp.sys.mac.misc,comp.sys.mac.programmer Subject: Re: PROPOSAL - Archive Standard Message-ID: Date: 20 Mar 91 02:53:38 GMT References: <6008@crystal9.UUCP> Sender: news@athena.mit.edu (News system) Distribution: comp Organization: Mass. Inst. of Tech., Dept. of Chemistry Lines: 96 In-Reply-To: derosa@motcid.UUCP's message of 14 Mar 91 22:55:12 GMT I too have been downloading stuff for our new machines. The kinds of problems are as described in the article above. I think the need for a standard is obvious, but we may not all have the same needs. On Unix systems the standard for binary transmission is a compressed tar. It retains directory structure, handles text and binary files. For mailing sources there are other standards. But, since machines connected to the net are largely not Macintosh, and there are unix tools to dehex, and unsit files, I reccomend the following modifications to the suggested standards. On 14 Mar 91 22:55:12 GMT, derosa@motcid.UUCP (John DeRosa) said: > Sumex Archival Standard for Macintosh - Revision 1.0 > ==================================================== > 1) If there is more than one document to be in the new > archive, put them in a folder. > This eases the > recovery process as it does not necessitate the > independant creation of a folder prior to recovery > nor does it litter the hard drive with multiple > "read me" files. > 2) Try as best as possible to have the name of each > file in the archve refer to the main file in some manner. > This will facilitate grouping "lost" files with > its parent file or application. > 3) If there is only a single document to be in the new > archive and it is less than 20K in size, DO NOT > compress the document. > Compression of a document > of this size benefits very little from the compression > and only serves to add another step to the recovery > process. > 4) If the document or folder is 20K or larger then compress > the document/folder with Compactor as a self-extracting > archive (.sea). Use Stuffit so we can peer at the contents on a Unix machine. > Why not Stuffit, you might ask? In this area I am > bending to popular demand, Compactor seems to be more > widely used and is purported to be faster. I personally > prefer Stuffit as it incorporates BinHqx decoding. A > large thank you to Raymond Lau for Stuffit that has > been so popular for so long. He set the standards. I > have been told that a later version of Compactor will > have BinHqx also. How about batch modes and hqx file > recombining? > Why self-extracting, you might ask? If the file is > self extracting, then the receiver does not > need Compactor when decompressing. A simple double > click and, poof, a folder is born. > 5) Encode the file in BinHqx format. Make sure that the > name of this final archive file reflects the content and > the version number of the program, if applicable. Names > such as file1.hqx are no help at all. Names like > acmetool.1.3.6b8.hqx makes things perfectly clear. > 6) When you mail the compressed and binhqx'd file to the > archives, be sure and add a short paragraph telling > what the program/file is all about, complete with > version number. > MAKE SURE THAT YOU ONLY USE 80 COLUMNS > or less for the paragraph width. If you go beyond > 80 columns, then the file is converted to a Lpunch > format. This adds another step to the recovery > process. A simple way of making sure this happens > is to add the .hqx file to the mailer first, then > use the right edge of the file as a guide. Do not > type to the right of the right edge of the file. 7) Save all documentation in ascii text files that can be read and printed on non-Mac machines. -- Frank Kolakowski ======================================================================= |lfk@athena.mit.edu or lfk@eastman1.mit.edu or kolakowski@wccf.mit.edu| | Lee F. Kolakowski M.I.T. | | Dept of Chemistry Room 18-506 | | 77 Massachusetts Ave. Cambridge, MA 02139 | | AT&T: 1-617-253-1866 #include | ======================================================================= ||Desert Storm - Lasers have made this the cleanest *dirty war* ever.|| =======================================================================