Updated the totally outdated TODO file.

1 files changed, 27 insertions, 90 deletions

diff --git a/TODO b/TODO
index 61b2e3f2..af386101 100644
--- a/TODO
+++ b/TODO
@@ -1,109 +1,46 @@
 
-LZMA Utils TODO List
---------------------
+XZ Utils To-Do List
+===================
 
-Major missing features
+Known bugs
+----------
 
-    Memory limits in the command line tool apply only to compression.
+    The test suite is too incomplete.
 
-    Threading support in the lzma command line tool is still primitive.
-    It cannot split a file in pieces yet.
+    If the memor usage limit is less than about 13 MiB, xz is unable to
+    automatically scale down the compression settings enough even though
+    it would be  possible by switching from BT2/BT3/BT4 match finder to
+    HC3/HC4.
 
-    The --list mode isn't implemented in the command line tool.
 
-    Handling of Multi-Block Stream information should be separated
-    from Stream encoder and decoder. Those would be useful to implement
-    multi-threaded coding in applications.
+Missing features
+----------------
 
-    Buffer to buffer coding is not implemented in liblzma. Probably
-    a naive version should be written first, which would simply wrap
-    things around lzma_stream. Later, there should be separate buffer
-    coding functions, that are slightly faster (less memcpy()) and
-    have smaller memory usage than the functions using lzma_stream.
+    "xz --list"
 
-    libzfile is not implemented.
+    xz could create sparse files when decompressing. (Some prototyping
+    has been done.)
 
-    LZMA filter doesn't support predefined history buffer.
+    xz doesn't support copying extended attributes, access control
+    lists etc. from source to target file.
 
+    Multithreaded compression
 
-Security
+    Multithreaded decompression
 
-    Search for bugs, especially security related issues. Security is
-    important in every piece of code in LZMA Utils, but it is extremely
-    important in the decoder part of liblzma.
+    Buffer-to-buffer coding could use less RAM (especially when
+    decompressing LZMA1 or LZMA2).
 
-    Subblock: If there is LZMA as a Subfilter but without EOPM, can it
-    trigger infinite loop when Subblock's "Unset Subfilter" flag is hit?
-
-    Similarly, can LZ decoder get stuck in infinite loop if the next
-    filter in the chain returns LZMA_STREAM_END but the decoded data
-    doesn't allow finishing the LZ decoding?
-
-
-Reliability
-
-    Create a test suite to be run with "make check".
-
-    Should we use strlimit() and getrlimit() for memory usage limitting?
-
-
-Performance
-
-    Benchmark the CRC code on non-x86 CPUs. Won't have huge effect on
-    overall speed, but it would still be nice to know what algorithm
-    variant is the best on different CPUs.
-
-
-Third party support
-
-    Add support for LZMA to various applications. This naturally requires
-    cooperating with the authors of the specific applications.
-      * GNU grep and GNU diffutils: BSD grep already uses zlib directly
-        instead of ugly shell scripts. It would be nice to get similar
-        feature into relevant GNU tools. With libzfile, multiple
-        compression formats would be easy to support.
-      * kioslave for KDE
-      * Magic for the `file' command
-      * GNU Midnight Commander
-      * GNU Texinfo
-      * The `man' command
-      * Package managers
-
-    Test the patches already written. The patches should be sent to
-    upstream developers _once_ LZMA Utils APIs are stable enough (so
-    people don't need to fix those patches all the time).
-
-    Mandriva has quite a few patches. Some of them are OK, some need
-    adapting for new LZMA Utils.
+    I/O library is not implemented. It will possibly be named libzzf.
 
 
 Documentation
+-------------
 
-    Revise the man page of lzma command line tool.
-
-    If the Doxygen docs aren't enough, write good Texinfo manual for
-    liblzma. It's been a long time I've even tried to build the Doxygen
-    docs, so they may look quite bad at the moment.
-
-    Document LZMA as an algorithm. It would be great to have detailed
-    description of the algorithm in English. Many people think, that
-    reading the source code is not the optimal way to learn how LZMA
-    works.
-
-
-Other
-
-    Some things return LZMA_PROG_ERROR with invalid options, some
-    LZMA_HEADER_ERROR. These must be checked carefully and made so
-    that LZMA_HEADER_ERROR is used only when the given option could
-    make sense in future version of libzma.
-
-    lzma_restrict vs. restrict
-
-    Usage of LZMA_RUN vs. LZMA_FINISH with Metadata coders.
+    Some tutorial is needed for liblzma. I have planned to write some
+    extremely well commented example programs, which would work as
+    a tutorial. I suppose the Doxygen tags are quite OK as a quick
+    reference once one is familiar with the liblzma API.
 
-    Port the Deflate implementation from 7-Zip into liblzma. 7-Zip's
-    Deflate compresses better than zlib, gzip or Info-ZIP. I don't
-    know if Deflate will be included in .lzma format (probably not),
-    but it's still useful once we also add support for .gz file format.
+    Document the LZMA1 and LZMA2 algorithms.