Updated the totally outdated TODO file.

This commit is contained in:
Lasse Collin 2009-07-18 14:34:08 +03:00
parent 64e498c89d
commit 366e436090
1 changed files with 27 additions and 90 deletions

117
TODO
View File

@ -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.
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.
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.
libzfile is not implemented.
LZMA filter doesn't support predefined history buffer.
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.
Security
Missing features
----------------
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.
"xz --list"
Subblock: If there is LZMA as a Subfilter but without EOPM, can it
trigger infinite loop when Subblock's "Unset Subfilter" flag is hit?
xz could create sparse files when decompressing. (Some prototyping
has been done.)
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?
xz doesn't support copying extended attributes, access control
lists etc. from source to target file.
Multithreaded compression
Reliability
Multithreaded decompression
Create a test suite to be run with "make check".
Buffer-to-buffer coding could use less RAM (especially when
decompressing LZMA1 or LZMA2).
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.
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.
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.
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.