On 11/01/2013 03:02 AM, William Wong wrote:
I wanted to add full compression support to Rust. Full support means
stream compression (good for http compression) and multiple call
compression (compressing large file with multiple batches of read).
To get to that point, the miniz.cpp and deflate API in Rust runtime
need to be enhanced to overcome a few limitations.
I've worked with the author of miniz.c (Rich Geldreich) to merge
changes into miniz.c on his codeline for the needed API for Rust, and
resolved the decompression bug in miniz's code when working with
gzip'ed file.
http://code.google.com/p/miniz/issues/detail?id=25&can=1
http://code.google.com/p/miniz/issues/detail?id=23&can=1
Awesome!
I've implemented a full set of deflate API in Rust to support stream
compression and multiple call compression, with caller-driven and
callee-driven pipe style API. Also I've written the Rust GZip library
with stream support like GZipReader and GZipWriter. For testing, I've
re-implemented most of the gzip command line program on top of the
Rust GZip library. Some performance data for the interested: Rust
compression is about 1.8 times slower, decompression is about 3 times
slower than gzip. Overall it seems solid. See
https://github.com/williamw520/rustyzip for the source.
Even more awesome!
Now I need help to merge the changes into the Rust master codeline.
There are couple things.
1. What license to assign for the new files? I use MPL currently.
APL2/MIT dual license. Just copy the same headers that exist on all the
other .rs files.
2. There's a new version of miniz.cpp needed for things to work. Is
the Rust runtime still open for C++ file changes?
This change is fine.
3. There are two new files for the deflate library (deflate.rs
<http://deflate.rs>) and the gzip library (gzip.rs <http://gzip.rs>).
Which Rust runtime library is the appropriate one to put them in?
Replace extra::flate with these two.
4. Should the command line tool rgzip stay in an outside codeline or
be merged into the Rust runtime? If merging in, where is a good place
for tools?
Not in mainline.
Note that libextra is slated to be broken up into a number of supported
but external crates in the near future, and this will probably end up in
its own crate. For now though I think the above strategy will work.
Regards,
Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
