Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
WHATWG streams #2
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.
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.
Note: This was originally created for the ORTC Spec, so my spec changes may not be entirely accurate for this spec here.
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.
It also has at least one (theoretical) advantage over the current API: If the reader is fast enough and uses
I also want to mention two remaining issues: