BTW we've been trying to redesign this module. This module is based on legacy Reader/Writer interfaces, but we've been deprecating them in favor of ReadableStream/WritableStream interfaces.

We tried to make std/archive/tar to use ReadableStream/WritableStream in #1985, but it needed to depend on unfinished web stream proposal, and we couldn't land it.

We'd appreciate if you could make progress along with this direction.

Thanks @kt3k, that's good to hear. My further proposals for this module are around quality of life usage (adding compression and convenience functions to make the API much more user friendly). They build upon the existing Reader usage however. Given this, and the desire to redesign the module, I can hold off if the redesign is now able to be progressed. I'd be happy to help progress, though streams are new to me. However, it looks like the unfinished web stream proposal is still unfinished and therefore continues to block the completion of #1985?

Yeah, it still blocks #1985, but I was wondering if there's some alternative way which avoids depending on the proposal, but still replaces Reader/Writer with web streams..

Yeah, it still blocks #1985, but I was wondering if there's some alternative way which avoids depending on the proposal, but still replaces Reader/Writer with web streams..

Apparently not

@crowlKats Are you able to articulate in layman's terms what is incomplete with your efforts in #1985? I've read your PR and the corresponding incomplete spec proposal but am missing the gap it plugs.

well, the spec proposal itself needs to land to be able to have #1985

Ah, are you saying then that the code you've written matches the proposed spec, but we can't land the PR until the spec lands first? Makes sense, thanks.