Updated the totally outdated TODO file.
This commit is contained in:
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.
|
||||
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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue