From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-03-06 18:19:06
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk