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, 58 insertions, 0 deletions
diff --git a/Build/source/utils/gzip/TODO b/Build/source/utils/gzip/TODO
new file mode 100644
index 00000000000..1335e632d18
--- /dev/null
+++ b/Build/source/utils/gzip/TODO
@@ -0,0 +1,58 @@
+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>.