Xref: utzoo comp.sys.mac.apps:4718 comp.sys.mac.misc:9769 comp.sys.mac.programmer:22798 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ftpbox!motsrd!motcid!derosa From: derosa@motcid.UUCP (John DeRosa) Newsgroups: comp.sys.mac.apps,comp.sys.mac.misc,comp.sys.mac.programmer Subject: PROPOSAL - Archive Standard Message-ID: <6008@crystal9.UUCP> Date: 14 Mar 91 22:55:12 GMT Distribution: comp Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL Lines: 109 I have just finished un-binhqx'ing, unstuffing and uncompacting 70 files from the Sumex archives and have endured just about every style of archived Macintosh files that could exist. I came to the conclusion that there should be a standard for how items should be archived prior to being placed in the Sumex archives. It would appear that the only standard is choice-du-jour, i.e. whatever the latest tool of choice is and whatever way the user feels like using it. In the dim dark past it was Packit, then came Stuffit, now Compactor is all the rage. Binhqx appears to be the only constant. The point is that having all of the archived documents in one format will ease the job of the receiving user. Even though MOST new archived programs are using Compactor, even this pseudo standard has variations, self-extracting or not, folders or not. By setting a standard and by streamlining the whole process of recovery, many man years of effort will be saved. Consider how many people recovery a particular document while only one person is involved in the archiving process. Adding a few steps to the front end will serve to benefit those of use at the receiving end. Ultimately, I would like to see a single tool and a single dialog window perform the complete recovery, BinHqx decode and de-compress. Batch processing also. I would like to propose a standard as outlined below. I know that this will generate many comments, and possibly settle nothing ;-), but maybe, just maybe the world will be a better place. 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). 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. I hope that I have added to the general good by this long winded diatribe. I sure that I will find out. -- = John DeRosa, Motorola, Inc, Cellular Infrastructure Group = = e-mail: ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net = = Applelink: N1111 = =I do not hold by employer responsible for any information in this message =