WHATWG streams

[lgrahl]

I've experimented with WHATWG streams for a few weeks. In my little demo it works pretty good now (apart from a few nits here and there that should be resolvable) and makes a much more composable API. Once more people start utilising WHATWG streams, piping from one stream to another or applying transformations can be made without much of a hassle. It also brings the advantage that data can be fed from the user application into the QUIC stream buffer directly without requiring to copy it.

I had to pause working on this as I need to work on my master thesis now. However, I don't want to hold back this idea any further and show you my current results. In case anyone else wants to jump in, feel free! Otherwise, I'll hopefully come back to this once I have some spare time.

Feedback welcome!

Spec

I've updated the spec but it's still work in progress. While methods and attributes of RTCQuicStream have been updated for WHATWG streams, general description and specification of the construction of a readable and a writable stream instance is still missing. However, you can have a look at the code if you want to see how I've written it for the demo.

The spec changes can be found here and on GitHub.

Note: This was originally created for the ORTC Spec, so my spec changes may not be entirely accurate for this spec here.

Demo

The demo can be started here and the code can be found here.

[annevk]

cc @ricea @domenic

[pthatcherg]

I looked at this a little closer, and it does have a certain elegance to it for reading and writing vs. the lower level approach we have right now.

But do we really want to take on the ReadableStream and WritableStream as dependencies? It just seems like so much extra complexity/dependency to pull in without a big win.

[annevk]

The big win would be platform consistency and being able to tee to transform streams and such. E.g., the web's networking API uses these same APIs (well, just ReadableStream for now).

[lgrahl]

It also has at least one (theoretical) advantage over the current API: If the reader is fast enough and uses byob mode, the data can be written directly into the buffer that has been provided by the user.

I also want to mention two remaining issues:

• writer.desiredSize does not return the value I'd like it to return. I use a ByteLengthQueuingStrategy with WritableStream and return a Promise in writer.write that resolves before all data of that write call has been written. Basically, writer.desiredSize as it is now does not factor in the remaining length of the currently pending write. (@annevk suggestions welcome)
• It would be good to have a WritableStreamBYOBWriter, see Brainstorming a buffer-reusing version of writable streams whatwg/streams#495 but this is a spec issue.

[annevk]

@ricea, @domenic, and @tschneidereit should be able to help with those issues.

[lgrahl]

Still believe this is one of the most key API wins we could achieve with QUIC.

[annevk]

@aboba what does the icebox label mean? To be clear, non-adoption of the Streams API will likely lead to objections from Mozilla, the TAG, Chrome's API owners, etc.

And not engaging on this matter with @lgrahl is just rather rude.

[aboba]

@annevk Seth's PR w3c/p2p-webtransport#70 provides some of the pre-requisites for support of WHATWG streams (such as support for readable and writable streams). @pthatcherg is looking into what additional changes are necessary. To reflect this work-in-progress, I've changed the label to "PR Exists".

[pthatcherg]

I just landed #16, which updates the explainer to use WHATWG streams.

[aboba]

Now that PR #19 has been merged, can we close this issue?

[ExE-Boss]

@aboba I think you mean PR #46.

[lgrahl]

Yep.