On Fri, Mar 6, 2020 at 7:48 AM Dominique Devienne via Boost
Hi. I'd very much welcome a clean pure C++ implementation of basic deflate compression, because the C code I saw did not give me a warm and buzzy feeling, honestly.
Yep, that's the goal. And we also want robust tests which cover corner cases and known bugs/fixes, along with 100% coverage.
I couldn't easily use this new library, if it lacked ZIP support.
Yes, ZIP, gZip, and other flavors of deflate (which really only differ in the additional material prepended or appended to the compressed data) should be supported, with a clean API.
And if that support allowed efficient *and* multi-threaded access to the ZIP entries, all the better. The raw file IO can still be serial, but at the very least the compression / decompression should be able to run in parallel on multiple threads, via ASIO.
Now this is a bridge too far :) I don't think we need to get Asio involved here. However, we should ensure that the interface we settle on does not present an obstacle to a third party implementing the parallel algorithm you describe on top of the deflate algorithm.
Lastly, a quick glance at the code showed plain enums vs enum classes, capitalized vs all-lowercased enums; such naming inconsistencies was surprising. Perhaps it's from "consistency" with zlib? Not sure it's a good idea. Pick a style and stick to it IMHO.
The ZLib in Beast (upon which this new project is based) is unfinished. It does work though, and is used for the permessage-deflate extension of Beast websocket. Beast users don't have to deal with the hassle of having a separate zlib dependency, so it has achieved its goal in that sense. However I did not put all of the polish and design work into it that it needs as I am only one person. I did port it to header-only C++ though, if you have a look you can see that it is considerably different from the original ZLib, with no small effort. It can be further improved. Regards