summaryrefslogtreecommitdiff
path: root/Build/source/utils/gzip/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/utils/gzip/TODO')
-rw-r--r--Build/source/utils/gzip/TODO58
1 files changed, 0 insertions, 58 deletions
diff --git a/Build/source/utils/gzip/TODO b/Build/source/utils/gzip/TODO
deleted file mode 100644
index 1335e632d18..00000000000
--- a/Build/source/utils/gzip/TODO
+++ /dev/null
@@ -1,58 +0,0 @@
-TODO file for gzip.
-
-Some of the planned features include:
-
-- Structure the sources so that the compression and decompression code
- form a library usable by any program, and write both gzip and zip on
- top of this library. This would ideally be a reentrant (thread safe)
- library, but this would degrade performance. In the meantime, you can
- look at the sample program zread.c.
-
- The library should have one mode in which compressed data is sent
- as soon as input is available, instead of waiting for complete
- blocks. This can be useful for sending compressed data to/from interactive
- programs.
-
-- Make it convenient to define alternative user interfaces (in
- particular for windowing environments).
-
-- Support in-memory compression for arbitrarily large amounts of data
- (zip currently supports in-memory compression only for a single buffer.)
-
-- Map files in memory when possible, this is generally much faster
- than read/write. (zip currently maps entire files at once, this
- should be done in chunks to reduce memory usage.)
-
-- Add a super-fast compression method, suitable for implementing
- file systems with transparent compression. One problem is that the
- best candidate (lzrw1) is patented twice (Waterworth 4,701,745
- and Gibson & Graybill 5,049,881). The lzrw series of algorithms
- are available by ftp in ftp.adelaide.edu.au:/pub/compression/lzrw*.
-
-- Add a super-tight (but slow) compression method, suitable for long
- term archives. One problem is that the best versions of arithmetic
- coding are patented (4,286,256 4,295,125 4,463,342 4,467,317
- 4,633,490 4,652,856 4,891,643 4,905,297 4,935,882 4,973,961
- 5,023,611 5,025,258).
-
- Note: I will introduce new compression methods only if they are
- significantly better in either speed or compression ratio than the
- existing method(s). So the total number of different methods should
- reasonably not exceed 3. (The current 9 compression levels are just
- tuning parameters for a single method, deflation.)
-
-- Add optional error correction. One problem is that the current version
- of ecc cannot recover from inserted or missing bytes. It would be
- nice to recover from the most common error (transfer of a binary
- file in ascii mode).
-
-- Add a block size (-b) option to improve error recovery in case of
- failure of a complete sector. Each block could be extracted
- independently, but this reduces the compression ratio.
-
-- Use a larger window size to deal with some large redundant files that
- 'compress' currently handles better than gzip.
-
-- Implement the -e (encrypt) option.
-
-Send comments to <bug-gzip@gnu.org>.