Re: [w3ctag/design-reviews] CompressStream (#410)

> 1. Have you considered using different classes for each compression algorithm rather than a constructor argument? e.g. `let s = new GzipCompressionStream();` this might make it easier to pollyfill new algorithms.

I discussed this with @CanonMukai but we preferred to use a single constructor. At least in Blink, new symbols on the global object are moderately expensive, and I wanted to avoid adding them unnecessarily.

My current thinking for polyfilling / user extensibility is to have a dictionary `CompressionStream.algorithms` where the keys are algorithm names and the values are factory functions. This also makes inspecting available algorithms easy.

> 2. If the compression algorithm remains an argument, please ensure that the value uses (and references in the spec) the HTTP Content Coding tokens: https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding

I hadn't considered this. My one reservation is that using "br" for Brotli seems a little obscure.

Filed as https://github.com/ricea/compression-streams/issues/7.

> 3. It might be useful to have a property to access the compression algorithm of the stream (and any future options).

Yes. One thing that needs more examination is that different algorithms will have different options. For example, gzip will eventually have a filename option. It's not immediately clear to me how to handle this.

Filed as https://github.com/ricea/compression-streams/issues/6.

> 4. It may be worth considering adding support for Brotli in V1.

The awkward thing about Brotli is that to support compression we need to add a 140KB dictionary to the binary. This is a difficult trade-off and I don't have good answer for it yet. Supporting decompression is nearly free, but does it make any sense to only support decompression?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/410#issuecomment-542036721

Received on Tuesday, 15 October 2019 04:57:59 UTC