Bring GzipSink/GzipSource to the rest of the targets

[Wavesonics]

Being able to use Gzip in common code would be a killer feature.

I surveyed the other options out there:

• Korge supports more targets, but not all of them, and has some limitations around using Gzip with streams
• KotlinxIO doesn't support it at all yet

Would love to see a pure KMP implementation of Gzip!

[swankjesse]

Are you specifically interested in JS and Wasm targets? We’ve already got gzip on JVM and Kotlin/Native.

[swankjesse]

Could you please share your use case for gzip on these other platforms? They’re usually sandboxed and the enclosing container can often handle this kind of thing for us.

[Wavesonics]

I've got GZiped resources that I need to be decompressed: a file format that involves portions of it being gziped. (an uncompressed binary header section, then the rest is compressed)

[swankjesse]

Do you need this to work on Wasm? In Node? In the browser?

[Wavesonics]

for my use case it would be WASM and JS.

But without supporting them all we wouldn't be able to use them in common code I don't think right?

[swankjesse]

Unfortunately there’s no built-in zlib on browser or Wasm platforms. That means whatever we would do in Okio would either embed zlib or depend on a third party port. I’m quite reluctant to do either!

I would like to see a standalone open source project do this! But we don’t need it and I think it’s a bit out of scope for us to integrate external libraries.

[Wavesonics]

I take your point.

I think browsers have support for it as of just a few years ago:
https://developer.mozilla.org/en-US/docs/Web/API/Compression_Streams_API

but that wouldn't solve WASI, so we still wouldn't get it in common code.

I actually have about half of Deflate implemented in KMP, the Huffman Codes part. I was going to move on to the LZ77 part, but the performance wasn't great so far, so I put the project down for now.

Well something to keep in mind maybe if things change down the line.

[JakeWharton]

Related: #1442