home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / Geneve / 9640news / CAT10 / JCOFFEY.ARK < prev    next >
Text File  |  2006-10-19  |  10KB  |  160 lines

  1. ?
  2.                          Some Thoughts on Archiving
  3.                            Jerry Coffey - Dec 1987
  4.      Al Beard did the TI community a service not only by writing a combined
  5.    archiving/Huffman-squeezing program, but by documenting and extending the
  6.    conventions used in Barry Traver's ARCHIVER program.  Barry Boone has
  7.    provided a striking demonstration of the powerful Lempel-Ziv-Welch
  8.    algorithm as well as his consumate skill at crafting fast, efficient
  9.    assembly code.  Dave Ramsey has just written a thoughtful piece on some
  10.    of the possibilities and needs to be met by library and compression
  11.    utilities.
  12.      In this remarkable atmosphere of creativity, it is difficult to keep
  13.    track of the exchange of ideas.  I would like to summarize some of these
  14.    exchanges to give everyone the flavor of what is happening and to
  15.    emphasize some of the issues and questions.  Barry Traver put his finger
  16.    on some of the concerns that need to be addressed in a series of comments
  17.    that are excerpted below:
  18.           "A multiplicity of ARCHIVERS with no set standard or
  19.         reasonable compatibility can indeed be a nightmare for the
  20.         average user (not to mention a real headache to Sysops!), as
  21.         owners of other computers well know (with any on-line time saved
  22.         by file compression sometimes outweighed by off-line time lost
  23.         trying to find which of a dozen different archivers must be used
  24.         to unpack the compressed file!).
  25.           I have no axe to grind for a particular method (I've
  26.         encouraged both Al Beard and Barry Boone in their efforts), but
  27.         I believe we need to work out something of benefit of the
  28.         average TI user and Sysops for the good of the entire TI
  29.         community.  More than others, TI'ers are dependent upon major
  30.         services and local BBS's for software (they certainly won't find
  31.         much in their local computer store!).
  32.           "Two thoughts about the need for standardization:
  33.           (1) although TI'ers are as a whole more technically
  34.         knowledgeable than owners of other computers (they have to be to
  35.         stay alive!), many are still just plain "users" and need to have
  36.         some user-friendliness built into archiving and unarchiving, so
  37.         that they won't waste time on downloading files and never be
  38.         able to figure out how to unpack them.
  39.           (2) I've heard reported complaints from local IBM Sysops about
  40.         people uploading mammoth packed files without giving any
  41.         indication of what particular method to use in unpacking them,
  42.         which cause a lot of trouble for Sysops.  If we can avoid this
  43.         sort of thing in the TI community, we should.
  44.           "One thought about one possible step for a solution to help
  45.         the confused user: have on a disk a collection of archivers with
  46.         a load program.  When the load program is run, it could ask for
  47.         the name of the file to be unpacked, and - after checking it out
  48.         - could then load the appropriate archiver (DCOPY, ARCHIVER,
  49.         SQUARC, ARCHIVER II 2.3, ARCHIVER III, etc.) for unpacking that
  50.         particular file (assuming that there are enough "flags" -
  51.         intentional and/or accidental - to distinguish the packed
  52.         files).  Just a thought on one thing that could be done if a
  53.         standard format _isn't_ worked out (although some
  54.         standardization would certainly be preferable, in my opinion).
  55.            WHY STANDARDIZATION?
  56.      In CPM and MSDOS, filename extensions play a critical role in
  57.    identifying file type for the operating system (e.g., COM, EXE, and BAT
  58.    files).  This same device has been used by agreed convention to indicate
  59.    collections of files combined in a "library" or "archive".  The extension
  60.    LBR or ARC conveys information about the structure of the combined file
  61.    to special utility programs, just as COM, EXE, and BAT convey information
  62.    to the operating system.  The new extensions and their meaning were
  63.    established not by the creators of the operating system, but by users
  64.    (and vendors) working together to improve performance of the system.
  65.      In the TI system, the role of filename extensions is played by the file
  66.    type byte in the file header.  Since this convention was established by
  67.    TI and has served the community very well, any elaboration of the file
  68.    type concept must be consistent with the TI protocol and be recognised
  69.    and accepted by programmers to be useful.
  70.      Al Beard proposed setting a single bit in the file type to flag
  71.    squeezed files.  A recent conference on Delphi explored some of the
  72.    possibilities here.  TI only used 10 out of the 256 bit combinations
  73.    available in the file type byte.  Setting other bits in the file type has
  74.    virtually no effect in existing programs (thus avoiding compatibility
  75.    problems).  Most important, this byte is preserved in the Paul Charlton
  76.    XMODEM implementation that has become the de facto standard for file
  77.    transfers.  It is also preserved in Traver and Beard archives and will be
  78.    probably be preserved in the full implementation of Barry Boone's program
  79.    (ARC III).  So here we have a common point of reference with the approach
  80.    used in CPM and MSDOS.
  81.      There are several possible uses that could be made of the unused bits
  82.    in the file type byte.  Dave Ramsey has pointed out the usefulness of
  83.    considering library and squeezing functions separately.  In the case of a
  84.    library or archive, the DF128 byte in the header that identifies the
  85.    combined file could have a bit set to distinguish an archive from
  86.    normally structured DF128 files.  (The Display/Fixed 128 format for
  87.    archived files has also become a de facto standard, in part to
  88.    distinguish them from the radically different concept <TI-DOS
  89.    independence> used in TI's unique "DCOPY" utility.)  For each file within
  90.    an archive, a "mini" header is written to identify the type and location
  91.    of the data records that constitute the packed file.  These mini-headers
  92.    preserve the file type bytes for the component files and are a natural
  93.    location for imbedding flags to indicate that a file has been squeezed,
  94.    for example.  Within any file type byte there are 15 variants that could
  95.    be distinguished by setting the "reserved bits".  But if Dave Ramsey is
  96.    right, this modest approach might come back to haunt us by restraining
  97.    further development.
  98.      That is the significance of any consensus on standards we can reach
  99.    now.  It will affect not only the ease of the transition to more powerful
  100.    file-handling utilities, but also the course of future development.
  101.            WHAT DEVELOPMENTS?
  102.      What is at stake?  Consider a few of the possibilities.  Even the
  103.    simplest Traver archive already has the potential for providing
  104.    subdirectories on floppy disks.  When you catalog the contents of an
  105.    archive, you are already looking at a subdirectory.  The files that are
  106.    pointed to by this directory are all intact and waiting to be used, but
  107.    the handles (file headers) needed by the operating system have been
  108.    condensed.  What is missing are the utility routines to read or print
  109.    text directly from the archive or to execute the programs.  How easy or
  110.    difficult it will be to write these routines may well depend on the form
  111.    of the mini-header.
  112.  
  113.      The 9640 (having a real-time clock) uses some of the bytes reserved by
  114.    TI in the file header for two time/date stamps, a use that TI probably
  115.    anticipated.  Since archives are very useful for long-term storage of
  116.    files, a date stamp can be very helpful in distinguishing similar files
  117.    of different vintages.  If this potential is to be preserved, the
  118.    mini-header must also preserve some of these reserved bytes along with
  119.    the bare necessities retained in the current format.  Note that these
  120.    bytes in the main archive header are not preserved in an XMODEM transfer
  121.    (FTG applies its own current date stamp when it writes a file on the user
  122.    disk), but date stamps in the mini headers within a transmitted archive
  123.    could be preserved.
  124.  
  125.      Another possibility might be the use of bits or bytes within the mini-
  126.    header to indicate more elaborate processing the files have been put
  127.    through, for example Huffman or LZW encoding.  This would permit files
  128.    compressed by different methods to inhabit the same archive and each file
  129.    could be correctly restored by selecting a routine based on the header
  130.    flags.  Al Beard is using a similar idea employing the first few words of
  131.    the encoded file, but consolidating this information in the mini-header
  132.    may be more efficient and adaptable.
  133.  
  134.      More ambitious possibilities include loading a file directly from an
  135.    archive on disk, unsqueezing if necessary, and then executing it
  136.    (program) or reading, printing, editing (text).  How about a directory
  137.    routine for TI-Writer (or FUNL or BA-) or MY-WORD that reads a
  138.    subdirectory, marks a file, and loads the file into the editor
  139.    (unsqueezing if necessary) -- and another that repacks the edited file
  140.    (with a revised date stamp) back into the same archive.  All of this is
  141.    possible with the right information in the mini-header and an appropriate
  142.    structure for the subdirectory.
  143.           CONSEQUENCES OF STANDARDS
  144.  
  145.      Since TI has left the field, the future is in the hands of the users.
  146.    We must accept responsibility for any effort to assure orderly
  147.    development of new software.  If standards don't permit enough room for
  148.    innovation, creative people will be frustrated and the user will suffer
  149.    with friendly but mundane software.  On the other hand a change to less
  150.    restrictive concepts requires a lot of things to make the new standard
  151.    work for the average user -- such things as conversion programs to update
  152.    existing files for compatibility.  This is not the sort of thing that can
  153.    be taken as a steady diet.  So it is important to agree on something we
  154.    can live with for a while.
  155.  
  156.  
  157. Download complete.  Turn off Capture File.
  158.  
  159.  
  160.