Intent to Ship: Compression Streams

[Adam Rice]

Contact emails

ri...@chromium.org, yhi...@chromium.org 

Explainer

https://github.com/wicg/compression/blob/master/explainer.md

Spec

https://wicg.github.io/compression/

TAG review

https://github.com/w3ctag/design-reviews/issues/410

Summary

Provides a means of performing gzip and deflate compression from JavaScript using streams. The CompressionStream API performs compression and the DecompressionStream API performs decompression.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://googlechromelabs-unarchiver.glitch.me/

Debuggability

Normal DevTools JavaScript debugging will work. No special support is needed.

Risks

Interoperability and Compatibility

The main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it. Browsers may produce different compressed output for the same input.

Firefox: Discussion: https://github.com/mozilla/standards-positions/issues/207. No official conclusion.

Edge: No official signals. Positive comment from Eric Lawrence: https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ.

Safari: Thread: https://lists.webkit.org/pipermail/webkit-dev/2019-November/030972.html. No public signals yet.

Web developers: Many positive signals. See https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ.

Ergonomics

The API is very minimal in this first version, which should make it easy to use. Developers familiar with the Streams API will be able to use it without learning anything new. The composability of Streams makes interoperability with other APIs such as TextEncoderStream easy.

Activation

CompressionStream and DecompressionStream can be polyfilled using a JavaScript or wasm implementation of the deflate algorithm. This should make it easy to adopt.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, including in-depth testing of error conditions. https://wpt.fyi/results/compression.

Entry on the feature dashboard

https://chromestatus.com/feature/5855937971617792

[Yoav Weiss]

LGTM1

Thanks for working on this! An important missing primitive that will enable significant data savings without forcing developers to reimplement those algorithms in JS or WASM (with the complexity and costs that this incurs)

On Wed, Dec 4, 2019 at 10:17 AM Adam Rice <ri...@chromium.org> wrote:

Contact emails

ri...@chromium.org, yhi...@chromium.org 

Explainer

https://github.com/wicg/compression/blob/master/explainer.md

Could you add an example of feature detection in the explainer or in the spec examples that would spell out how developers can detect lack of support for this, and what they are expected to do? (e.g. download a gzip polyfill, or not compress)

 

Spec

https://wicg.github.io/compression/

TAG review

https://github.com/w3ctag/design-reviews/issues/410

Summary

Provides a means of performing gzip and deflate compression from JavaScript using streams. The CompressionStream API performs compression and the DecompressionStream API performs decompression.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://googlechromelabs-unarchiver.glitch.me/

Debuggability

Normal DevTools JavaScript debugging will work. No special support is needed.

Risks

Interoperability and Compatibility

The main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it. Browsers may produce different compressed output for the same input.

Firefox: Discussion: https://github.com/mozilla/standards-positions/issues/207. No official conclusion.

Edge: No official signals. Positive comment from Eric Lawrence: https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ.

Safari: Thread: https://lists.webkit.org/pipermail/webkit-dev/2019-November/030972.html. No public signals yet.

Web developers: Many positive signals. See https://groups.google.com/a/chromium.org/d/msg/blink-dev/9gaUKa3QmmE/z_Ef9Xr_DQAJ.

Thanks for reaching out to other vendors! :)

 

Ergonomics

The API is very minimal in this first version, which should make it easy to use. Developers familiar with the Streams API will be able to use it without learning anything new. The composability of Streams makes interoperability with other APIs such as TextEncoderStream easy.

Activation

CompressionStream and DecompressionStream can be polyfilled using a JavaScript or wasm implementation of the deflate algorithm. This should make it easy to adopt.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, including in-depth testing of error conditions. https://wpt.fyi/results/compression.

Entry on the feature dashboard

https://chromestatus.com/feature/5855937971617792

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwEu-m_%2BWZ85TXSWMx02%2BKOaC1Oqx5--g07_BqDnsqvDg%40mail.gmail.com.

[Mike West]

LGTM1.

The TAG review feels positive, as does the conversation on Mozilla's tracker, and y'all have engaged on the issues raised admirably. The WPT suite looks fairly comprehensive (though Blink fails 8 tests, which seems like something we could address).

There's one question that I didn't see an answer to: if we want to support options in the future (by passing in a dictionary as suggested in https://github.com/w3ctag/design-reviews/issues/410#issuecomment-542044821), does anything in the current implementation preclude us from doing so? It seems like we'd just be able to add that to the constructor fairly cleanly...

-mike

On Wed, Dec 4, 2019 at 10:17 AM Adam Rice <ri...@chromium.org> wrote:

[Adam Rice]

The WPT suite looks fairly comprehensive (though Blink fails 8 tests, which seems like something we could address).

They all pass on ToT. I'm not sure why they're failing on wpt.fyi.

There's one question that I didn't see an answer to: if we want to support options in the future (by passing in a dictionary as suggested in https://github.com/w3ctag/design-reviews/issues/410#issuecomment-542044821), does anything in the current implementation preclude us from doing so? It seems like we'd just be able to add that to the constructor fairly cleanly...

You had a race condition with Yoav on this one. He filed https://github.com/WICG/compression/issues/22.

I haven't answer this in the specification or explainer, because it feels weird to talk about things I'm not planning to add yet.

[TAMURA, Kent]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwEu-m_%2BWZ85TXSWMx02%2BKOaC1Oqx5--g07_BqDnsqvDg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Adam Rice]

They all pass on ToT. I'm not sure why they're failing on wpt.fyi.

Looks like the version of Chrome on wpt.fyi was just too old. The same tests are passing now:  https://wpt.fyi/results/compression.