We are implementing the "deflate-raw" compression codec for compression streams. This is similar to "deflate" but lacks a header and footer. In other words, it is pure RFC1951, unlike "deflate" which is actually RFC1950, "ZLIB Compressed Data Format". The awkward naming is for compatibility with HTTP Content-Encodings. One of the major use cases for this is implementing the ZIP format, which otherwise requires some ugly hacks: https://github.com/WICG/compression/issues/25#issuecomment-850959782 This is a tiny addition, so I haven't created a new thread for it. Any feedback is welcome. Thanks, Adam Rice, Chromium On Thu, 13 Aug 2020 at 08:37, Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi all,
This is a very belated reply but what's being proposed seems reasonable to us (Apple's WebKit team). We would like to know more about use cases, and how they might be deployed in real websites / use cases but we don't see any major issues with it.
- R. Niwa
On Wed, Nov 27, 2019 at 11:18 PM Thomas Steiner <tomac@google.com> wrote:
You can see DecompressionStream in action in unarchiver, this is the
relevant code snippet (run it in Chrome 79+ with the chrome://flags/#native-file-system-api and the chrome://flags/#enable-experimental-web-platform-features flags set).
On Thu, Nov 28, 2019 at 6:07 AM Adam Rice <ricea@chromium.org> wrote:
I am trying to gauge feedback on compression streams with a view to
shipping them in Chromium.
Very briefly, they are a way to do gzip and gunzip in the browser. Less
briefly, the explainer https://github.com/WICG/compression/blob/master/explainer.md goes into some detail of the how and why. The specification https://wicg.github.io/compression/ gives verbose detail of how. You may also find the W3C TAG review https://github.com/w3ctag/design-reviews/issues/410 interesting.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev