home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compress / 2805 < prev    next >
Encoding:
Text File  |  1992-07-25  |  7.1 KB  |  182 lines
  1. Newsgroups: comp.compression
  2. Path: sparky!uunet!darwin.sura.net!Sirius.dfn.de!chx400!bernina!neptune!umueller
  3. From: umueller@iiic.ethz.ch (Urban Dominik Mueller)
  4. Subject: XPK compression standard (long)
  5. Message-ID: <1992Jul25.232049.7685@neptune.inf.ethz.ch>
  6. Sender: news@neptune.inf.ethz.ch (Mr News)
  7. Nntp-Posting-Host: c11
  8. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  9. Date: Sat, 25 Jul 1992 23:20:49 GMT
  10. Lines: 170
  11.  
  12. Since there is comp.compression.research now, I can dare to talk about
  13. something as trivial as a new standard for compression programs. I have
  14. implemented an interface between applications and compression programs
  15. that makes both sides exchangeable. The result is called XPK as for 
  16. 'eXternal PacKer'. The only implementation yet exists on the Amiga, and
  17. I'm very interested in hearing from you in case you are interested in
  18. porting it to any other platforms. Note that one key element of the XPK
  19. standard are late-binding libraries (like .DLL on PC's) which should
  20. be provided by the respective OS.
  21.  
  22. Here comes the description:
  23. --------------------------------------------------------------------
  24.  
  25.  
  26. XPK - A NEW STANDARD FOR DATA COMPRESSION
  27. =========================================
  28.  
  29. MOTIVATION
  30. ----------
  31. * Many programs that should offer data compression (e.g. HD backup utilities)
  32.   don't.
  33. * Many programs that offer data compression use an old, slow, inefficient or
  34.   inappropriate algorithm.
  35. * All programs that offer data compression offer just one algorithm, you're
  36.   stuck with that one.
  37. * Many good packers are not used by any application program and have no
  38.   good user interface.
  39. * The installation of most packers requires AmigaShell knowledge (putting
  40.   LHarc in the path so that DiskMaster can find it)
  41. * The decompression of all files packed with existing packers requires
  42.   knowledge about the packer used for compression.
  43. * Many compression programs can not deal with files that are larger than
  44.   available memory.
  45. * The existing compression programs are either slow or have a low 
  46.   compression factor.
  47. * There is no way to support upcoming hardware compression cards in already
  48.   existing applications yet.  
  49. * For none of the current compression programs exists a real decompressing 
  50.   file handler that uses no dirty tricks to decompress files on the fly.
  51.  
  52. The solution to all these problems is xpk.
  53.  
  54.  
  55. OVERVIEW
  56. --------
  57. The xpk standard is to data compression what xpr is to file transmission.
  58. It consists of three layers:
  59. Level 2: The application/xpk interface for archives (planned)
  60. Level 1: The application/xpk interface for files
  61. Level 0: The xpk/packer interface
  62. In addition, there is an optional standard xpk file format.
  63.  
  64. All parts of the xpk standard are implemented in shared libraries. There
  65. is one master library for archive level access, one master library for file
  66. level access, and one library for each compression algorithm.
  67.  
  68. level 2            xpkarchive.library
  69.                            |
  70.                            V
  71. level 1             xpkmaster.library
  72.                      /     |     \
  73.                     /      |      \
  74.                    V       V       V
  75. level 0          xpkNUKE  xpkZOO  xpkLHARC
  76.  
  77.  
  78.  
  79. LEVEL 0 LIBRARIES
  80. -----------------
  81. All level 0 libraries offer the same functions. They're very small. Typical 
  82. calls are: "Tell me what you can", "Compress this chunk of memory to another
  83. chunk of memory", and "Decompress this chunk of memory to another chunk of
  84. memory". These libs are very limited, their functionality is expanded by
  85. xpkmaster.library. No one would want to talk to a sub library directly.
  86.  
  87.  
  88. THE LEVEL 1 LIBRARY
  89. -------------------
  90. Offers functions like "Compress this file to that chunk of memory using that
  91. algorithm". All combinations permitted: Mem to mem, file to file, mem to file,
  92. decompression and compression. Asynchronous packing possible. Very convenient
  93. tag based caller interface. Automatically finds out which sub library to use
  94. for decompression. Returns detailed error messages.
  95.  
  96.  
  97. THE LEVEL 2 LIBRARY
  98. -------------------
  99. Offers archiving functions like "add this file to that archive" or "show
  100. me the contents of that archive". Not implemented yet.
  101.  
  102.  
  103. OVERRIDING
  104. ----------
  105. Libraries of a lower level can offer higher level functions. They then 
  106. override the automatic functinality expansion by the higher level library.
  107. xpkmaster.library, for example, enforces the use of the xpk standard file
  108. format unless overridden by a sub library.
  109.  
  110.  
  111. THE XPK FILE FORMAT
  112. -------------------
  113. Offers checksums, chunks (important when Seek()s on a compressed file become
  114. necessary) and automatic handling by the xpkmaster.library. This means that
  115. any new packer that can only pack mem to mem has its own file format 
  116. immediately. And most important: The name of the packer library is contained
  117. in the file. Therefore, copying a new sub library to LIBS: is all you
  118. have to do to install a new packer (easily done in installation scripts);
  119. xpkmaster.library recognizes the new file type immediately. No changes to 
  120. xpkmaster.library or the application programs necessary. In case the xpk
  121. file format is not used, the introduction of a new packer requires a change
  122. the xpkmaster.library.
  123.  
  124.  
  125. THE EXISTING PACKERS
  126. --------------------
  127. Two excellent unpublished compression programs already use the xpk standard.
  128.  
  129. * BLZW (Bryan's LZW)
  130.   Combines unseen compression speed with fast decompression speed and a
  131.   resonable compression factor. Timings on the 25 MHz A3000:
  132.  
  133.   Compression speed  : 100-120K/sec
  134.   Decompression speed: 200-250K/sec
  135.   Compression factor : Like ZOO
  136.  
  137. * NUKE
  138.   Designed for lightning fast decompression while retaining a good compresion
  139.   factor.
  140.  
  141.   Compression speed  :  30- 40K/sec
  142.   Decompression speed: 650-700K/sec
  143.   Compression factor : Like LHarc, 1-2% worse
  144.  
  145. * PowerPacker
  146.   Is supported for decompression only. This is a hack in the xpkmaster.library.
  147.  
  148. For comparison: The fastest packer so far (Zoo) packs 35K/sec, the fastest
  149. unpacker so far (Imploder) decompresses 240K/sec. Detailed statistics are
  150. available.
  151.  
  152.  
  153. TYPICAL APPLICATIONS
  154. --------------------
  155. A few examples for applications that could use xpk:
  156. * A GadTools based archiver interface that can deal with all archivers
  157. * A CLI based file compressor/decompressor
  158. * A hard disk backup utility that stores compressed data
  159. * A 'more' program with automatic decompression
  160. * A DTP program that stores its fonts in compressed format
  161. * A network protocol with built in data compression for slow connections
  162. * A hypertext utility that allows all data to be compressed
  163. * A file handler that overlays an existing filesystem and uncompresses any 
  164.   file while loading
  165. ...plus many more we don't even need to think about yet.
  166.  
  167.  
  168. OTHER USES FOR XPK
  169. ------------------
  170. Xpk could become an all purpose file conversion facility. E.g. it could
  171. be used to convert JPEG images to IFF images while loading them into
  172. DPaint, or encrypt files, or add redundancy to files for error correction.
  173.  
  174.  
  175. CONCLUSION
  176. ----------
  177. Xpk would increase the usefulness and flexibility of both application and 
  178. compression programs while improving their user friendliness at the same
  179. time.
  180.  
  181.  U. Dominik Mueller              umueller@amiga.physik.unizh.ch
  182.