source: vendor/gzip/1.3.11/TODO@ 3544

Last change on this file since 3544 was 3325, checked in by bird, 18 years ago

gzip 1.3.11

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