maint: prefer HTTPS to HTTP, FTP in URLs

[debian/gzip] / TODO

diff --git a/TODO b/TODO
index 865be9250782efaa0b0be10d204b7194288bbf48..604ea4993e2e9658afaba268dc2b2cdc980eb7da 100644 (file)
--- a/TODO
+++ b/TODO
@@ -2,6 +2,13 @@ TODO file for gzip.
 
 Some of the planned features include:
 
+- Remove some of the old porting cruft, since we no longer support it.
+
+- Separate out the shell scripts like gzexe into a new little package;
+  these scripts are less used and less reliable and should be optional.
+
+- Internationalize by using gettext and setlocale.
+
 - 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)
@@ -24,16 +31,14 @@ Some of the planned features include:
   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*.
+  file systems with transparent compression. The lzrw series of algorithms
+  are available at http://www.ross.net/compression/.
 
 - 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).
+  term archives.  See, for example, US Patents 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, which have all expired.
+  More recent patent-free techniques may also be available.
 
   Note: I will introduce new compression methods only if they are
   significantly better in either speed or compression ratio than the
@@ -50,9 +55,26 @@ Some of the planned features include:
   failure of a complete sector. Each block could be extracted
   independently, but this reduces the compression ratio.
 
+  For one possible approach to this, please see:
+
+    https://ozlabs.org/~rusty/gzip.rsync.patch
+
 - 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 Jean-loup Gailly <jloup@chorus.fr>.
+
+Send comments to <bug-gzip@gnu.org>.
+
+
+========================================================================
+
+Copyright (C) 1999, 2001, 2006, 2009-2017 Free Software Foundation, Inc.
+Copyright (C) 1992, 1993 Jean-loup Gailly
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
+Texts.  A copy of the license is included in the ``GNU Free
+Documentation License'' file as part of this distribution.