forked from tukaani-project/xz
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Updated the totally outdated TODO file.
- Loading branch information
Showing
1 changed file
with
27 additions
and
90 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. | ||
|