home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / Geneve / 9640news / CAT01 / ABEARD.ARK < prev    next >
Text File  |  2006-10-19  |  7KB  |  164 lines
  1. ?
  2.  
  3.    Comments to Dave Ramsey's and Jerry Coffey's Comments on Archiving
  4.    ------------------------------------------------------------------
  5.  
  6.   These are comments to Dave Ramsey's and Dr. Jerry Coffey's thoughts
  7.   on archiving and squeezing (crunching) files.  I appreciate thier
  8.   inputs.
  9.  
  10.   First, Dr. Jerry Coffey's comments.  I find myself in almost complete
  11.   agreement with Jerry, and his excerpts from Barry Traver.  I think
  12.   Barry Boone is onto something great with his LZW algorithm, and
  13.   have said so several times.   I expect that LZW will indeed prove
  14.   to be superior (both in terms of speed and packing density) in most
  15.   cases over Huffman encoding.
  16.  
  17.   As much as I admire Barry Boone for his work on the LZW archiver,
  18.   (and golly, I didn't even know that he had an archiver when I wrote
  19.   mine), I think it is unfortunate that he released it in the state
  20.   it was in.  It was obvious that it was released under duress, per
  21.   his own comments in the documentation (question, Barry, why did you
  22.   feel under pressure to release it?, older software simply moves aside
  23.   when faced with newer, better stuff).  All I can say, Barry, is make
  24.   it backwards compatible to previous stuff, and I'll tell the world
  25.   how you walk on water).
  26.  
  27.   Lets get back to basics.  My concept of an archive is a means to collect
  28.   a group of (hopefully related) files together in a single file, so that
  29.   the files can be recovered conveniently at a later date.  A good
  30.   archiver should have the following characteristics:
  31.  
  32.     1. It should pack the files quickly and easily from/to all devices
  33.        currently supported by the target machine.
  34.  
  35.     2. It should allow inspection of the archive without necessarily
  36.        needing to unpack the original file.
  37.  
  38.     3. It should minimize the resulting archive file size, so that
  39.        the time taken to upload or download a file to the networks can
  40.        be minimized (i.e. file compression methods).  Due to limitations
  41.        on compression techniques, the archiver should have several
  42.        techniques available, and automatically pick the best for
  43.        the particular operation.
  44.  
  45.     4. Archiving/Dearciving MUST be a single step operation, i.e. I
  46.        don't want to dearchive a file, just to find out that I have
  47.        to run it through another decompression step.  Or I don't want
  48.        to uncompress the archive, creating another file, just to
  49.        have to then invoke the archiver.  (How many unique names for
  50.        files can I think of anyway?)
  51.  
  52.     5. A requirement pointed out on DELPHI is that the resulting
  53.        format for the archive should tell the downloader at the time
  54.        of downloading which archive method was used to pack the
  55.        archive.
  56.  
  57.     6. The archiver should support the new MDOS formats for the
  58.        Geneve.
  59.  
  60.     7. The archiver should automatically recognize the different
  61.        formats in which the archive might have been packed, and
  62.        unpack it appropriately.
  63.  
  64.     8. The archiver doesn't necessarily have to pack in all formats
  65.        as in (7).  It would be nice if it could optionally create
  66.        an archive in TRAVER format, since this is the base which
  67.        everybody SHOULD be able to read.
  68.  
  69. Now, for Dave's concerns:
  70.  
  71.     1. >Directory entries aren't powers of two.
  72.  
  73.        Yes, but this isn't a major programming problem.  Is it really
  74.        important that the archiver keep the original dates on all of
  75.        the files that make it up?  The archive itself can easily include
  76.        a date for the whole archive.  It probably would be good to
  77.        extend the header, though, for future use (although that use
  78.        has to be carefully delegated).
  79.  
  80.     2. >Bytes 12-13, unusual use ->  How can the archiver (dearchiver)
  81.        figure out where each file starts if the file is squeezed?  I
  82.        realize later on that you state that the files should be squeezed
  83.        externally to the archiver, but, given that the archiver does
  84.        do compression, how can it figure this out if this is the unsqueezed
  85.        sector count?
  86.  
  87.     3. >Create fixed number of library entries ->  Not a bad idea.  I
  88.        think that the present format, however, can accomodate needed
  89.        operations (e.g. delete file, update file, add file, etc.)
  90.        similar to the way it is done in MSDOS by rewriting the entire
  91.        archive.
  92.  
  93.     4. >Seperate the archiving process from the compression process:
  94.        Dave, this is probably my most serious disagreement.  I realize
  95.        that the CPM world has been living this way, but when I dearchive
  96.        a file, I don't want to have to mess with a file coming out of
  97.        the archive (which may have been archived in one of several
  98.        different methods), and then finding a decompression program to
  99.        decompress it (which may have been compressed in one of several
  100.        different formats).
  101.  
  102.  
  103. The archiver that gets my vote WILL:
  104.  
  105.     1. Have speedy compression built right in
  106.     2. Let me inspect any archive before unpacking it
  107.     3. Picks the best compression algorithm
  108.     4. Is compatible (for listing and unpacking) with all previous
  109.        formats
  110.     5. Provides for future expansion (as Dave points out) into the
  111.        Geneve.
  112.  
  113.  
  114. I am going to be bold and suggest to Barry Boone what I would like to see in
  115. his next formal archiver release:
  116.  
  117.    1. Inclusion of the compression algorithm on a file by file basis.
  118.  
  119.    2. The "compression" type flag should be unique to the new archive
  120.       format.
  121.  
  122.    3. A check at the end of the compression to make sure the compressed
  123.       file is not larger than the original, and if so, repack it.
  124.  
  125.    4. Inclusion of the Huffman encoding "unpack" algorithm, so that
  126.       the archiver can unpack older Huffman encoded files (note that
  127.       this algorithm is trivial in comparison to the packing algorithm).
  128.       Also, automatic recognition and unpacking of TRAVER unsqueezed
  129.       formats on a file by file basis in the archive.
  130.  
  131.    5. The new archive file format should be whatever is the most efficient
  132.       for the TI-99 and Geneve (Paul Charlton, suggestions here?), but
  133.       should recognize for unpacking the older dis/fix/128 formats.
  134.  
  135.    6. Bits in the archive file header which indicate the compression
  136.       algorithm used (yours would be the first to use this, so pick it).
  137.  
  138.    7. Expansion of the archive file headers to include the additional
  139.       Geneve time & date fields, and perhaps with suggestions from
  140.       the MDOS community on what fields might be up and coming.
  141.  
  142. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  143. SPECIAL NOTE TO BARRY BOONE:!
  144. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  145. Of course, Barry, this are only suggestions.  Your program is yours to do
  146. with as you wish.   Don't feel pressured, by ANYONE, INCLUDING ME, to
  147. release something, do something, compromise your program in any way that
  148. YOU don't feel is the right way (although listening to suggestions is
  149. always productive, and may give you ideas that you hadn't thought of).
  150.  
  151. YOU know your program the best, and YOU have to make the technical decisions
  152. of what is feasible over what is desirable.
  153.  
  154. (soap box concluded)
  155.  
  156.   Al Beard
  157. December, 1987
  158.  
  159.  
  160.  
  161. Download complete.  Turn off Capture File.
  162.  
  163.  
  164.