TODO

   1 TODO file for gzip.
   2
   3 Some of the planned features include:
   4
   5 - Remove some of the old porting cruft. since we no longer support
   6   FIXME-2011: in mid to late 2011, remove the following directories:
   7   amiga, atari, msdos, nt, os2, vms
   8
   9 - Separate out the shell scripts like gzexe into a new little package;
  10   these scripts are less used and less reliable and should be optional.
  11
  12 - Internationalize by using gettext and setlocale.
  13
  14 - Structure the sources so that the compression and decompression code
  15   form a library usable by any program, and write both gzip and zip on
  16   top of this library. This would ideally be a reentrant (thread safe)
  17   library, but this would degrade performance. In the meantime, you can
  18   look at the sample program zread.c.
  19
  20   The library should have one mode in which compressed data is sent
  21   as soon as input is available, instead of waiting for complete
  22   blocks. This can be useful for sending compressed data to/from interactive
  23   programs.
  24
  25 - Make it convenient to define alternative user interfaces (in
  26   particular for windowing environments).
  27
  28 - Support in-memory compression for arbitrarily large amounts of data
  29   (zip currently supports in-memory compression only for a single buffer.)
  30
  31 - Map files in memory when possible, this is generally much faster
  32   than read/write. (zip currently maps entire files at once, this
  33   should be done in chunks to reduce memory usage.)
  34
  35 - Add a super-fast compression method, suitable for implementing
  36   file systems with transparent compression. One problem is that the
  37   best candidate (lzrw1) is patented twice (Waterworth 4,701,745
  38   and Gibson & Graybill 5,049,881). The lzrw series of algorithms
  39   are available by ftp in ftp.adelaide.edu.au:/pub/compression/lzrw*.
  40
  41 - Add a super-tight (but slow) compression method, suitable for long
  42   term archives.  One problem is that the best versions of arithmetic
  43   coding are patented (4,286,256 4,295,125 4,463,342 4,467,317
  44   4,633,490 4,652,856 4,891,643 4,905,297 4,935,882 4,973,961
  45   5,023,611 5,025,258).
  46
  47   Note: I will introduce new compression methods only if they are
  48   significantly better in either speed or compression ratio than the
  49   existing method(s). So the total number of different methods should
  50   reasonably not exceed 3. (The current 9 compression levels are just
  51   tuning parameters for a single method, deflation.)
  52
  53 - Add optional error correction. One problem is that the current version
  54   of ecc cannot recover from inserted or missing bytes. It would be
  55   nice to recover from the most common error (transfer of a binary
  56   file in ascii mode).
  57
  58 - Add a block size (-b) option to improve error recovery in case of
  59   failure of a complete sector. Each block could be extracted
  60   independently, but this reduces the compression ratio.
  61
  62   For one possible approach to this, please see:
  63
  64     http://www.samba.org/netfilter/diary/gzip.rsync.patch
  65
  66 - Use a larger window size to deal with some large redundant files that
  67   'compress' currently handles better than gzip.
  68
  69 - Implement the -e (encrypt) option.
  70
  71 Send comments to <bug-gzip@gnu.org>.
  72
  73
  74 ========================================================================
  75
  76 Copyright (C) 1999, 2001, 2006, 2009-2016 Free Software Foundation, Inc.
  77 Copyright (C) 1992, 1993 Jean-loup Gailly
  78
  79 Permission is granted to copy, distribute and/or modify this document
  80 under the terms of the GNU Free Documentation License, Version 1.3 or
  81 any later version published by the Free Software Foundation; with no
  82 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
  83 Texts.  A copy of the license is included in the ``GNU Free
  84 Documentation License'' file as part of this distribution.