search

Frommi / miniz_oxide

Rust replacement for miniz
MIT License
179 stars 49 forks source link

Plans for C API #8

Open oyvindln opened 7 years ago

oyvindln commented 7 years ago

Would it be okay with some slight differences in output from the compressor compared to miniz? E.g I think it would be interesting to attempt implementing this matching algorithm as it looks like it could give significant performance improvements at higher compression levels.

There are also some minor compression level improvements that we could make, miniz doesn't do matches with the first byte, and does a very simple block type selection that doesn't always produce great results on very short input. (As opposed to zlib.)

Should we keep the compressor/decompressor structs exactly the same, or is it enough that inflate/deflateinit etc behave the same way?

I also propose we separate the C api part(the extern c exports) as a separate wrapper crate to avoid possible symbol conflicts when using it as a rust library and don't have to create the c static lib when we don't need it.

Frommi commented 7 years ago

I think it would be okay, the important part is to preserve ABI and error model.

Well, the compressor struct as well as mz_stream are already changed. It is okay though, because ABI only has pointers to these structs.

Good idea, to separate C part. Also, right now we have original tinfl_decompress in output object file which is used in miniz_zip.c, for example, but it is also used in tests. We should probably delete miniz_stub completely as well, as it was only useful during the development stage.

My internship is nearing its end though, so I wouldn't be able to devote as much time.

oyvindln commented 7 years ago

The project is now split between a C API shim which contain the C exports, and miniz_oxide itself, found in the miniz_oxide directory. It needs a proper C header and some cleanup still.