LZMA Utils TODO List -------------------- Major missing features Memory limits in the command line tool apply only to compression. 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. Security 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. 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. 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. 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.