aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2009-07-18 14:34:08 +0300
committerLasse Collin <lasse.collin@tukaani.org>2009-07-18 14:34:08 +0300
commit366e436090a7a87215e9bf0e3ddcd55f05b50587 (patch)
treef44ecff4d26cb66f56fa285836cdf7d1d3f7d614
parentAdded public domain notice into a few files. (diff)
downloadxz-366e436090a7a87215e9bf0e3ddcd55f05b50587.tar.xz
Updated the totally outdated TODO file.
-rw-r--r--TODO117
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.