🚀 go-pugleaf

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 =