mirror of https://git.tukaani.org/xz.git
Updated the totally outdated TODO file.
This commit is contained in:
Lasse Collin
parent
64e498c89d
commit
366e436090
117
TODO
117
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.
|
If the memor usage limit is less than about 13 MiB, xz is unable to
|
||||||
It cannot split a file in pieces yet.
|
automatically scale down the compression settings enough even though
|
||||||
|
it would be possible by switching from BT2/BT3/BT4 match finder to
|
||||||
The --list mode isn't implemented in the command line tool.
|
HC3/HC4.
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
Security
|
Missing features
|
||||||
|
----------------
|
||||||
|
|
||||||
Search for bugs, especially security related issues. Security is
|
"xz --list"
|
||||||
important in every piece of code in LZMA Utils, but it is extremely
|
|
||||||
important in the decoder part of liblzma.
|
|
||||||
|
|
||||||
Subblock: If there is LZMA as a Subfilter but without EOPM, can it
|
xz could create sparse files when decompressing. (Some prototyping
|
||||||
trigger infinite loop when Subblock's "Unset Subfilter" flag is hit?
|
has been done.)
|
||||||
|
|
||||||
Similarly, can LZ decoder get stuck in infinite loop if the next
|
xz doesn't support copying extended attributes, access control
|
||||||
filter in the chain returns LZMA_STREAM_END but the decoded data
|
lists etc. from source to target file.
|
||||||
doesn't allow finishing the LZ decoding?
|
|
||||||
|
|
||||||
|
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?
|
I/O library is not implemented. It will possibly be named libzzf.
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
Documentation
|
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
|
Document the LZMA1 and LZMA2 algorithms.
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue