On Fri, Mar 6, 2020 at 12:50 PM Janson R. via Boost
I have recently been working on a C++ compression library very similar to zlib after trying to implement some HTTP compression support over Boost.Beast and realizing after some discussion with sir Falco that while it would be a nice builtin feature for Beast, it would possibly be a better idea to have zlib-like compression be a separate library in order to be properly maintainable and likely more useful.
Do you thing that this could be useful to have as its own entity in the Boost environment? Any kind of feedback on the idea and the library is warmly welcome.
(As someone who had to recently peek into the zlib C source code...) 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. I need access to ZIP files, and since minizip and zlib are pretty much intertwined, as far as I saw, I couldn't easily use this new library, if it lacked ZIP support. 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. I'm dealing with ZIP files which reach into the 100,000s to millions of entries, and having to serially read+uncompress or compress+write per entry is slow! All those cores could be put to good use. 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. Thanks, --DD