Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
WHATWG Streams #2
It looks like the WHATWG spec has had a fair amount of churn, based on this comment: "Although readable streams have been significantly evolved recently due to implementation progress providing feedback, writable streams have not yet caught up to all the discoveries in that space. As such, while the following spec will be the basis for a final API, it is expected to change in several important ways before being ready to ship. Please follow along on the writable streams issues label for details. "
I think we should probably review the changes to the spec since our implementation was last touched 5-7 months ago.
FWIW, I believe that part about writable streams was there when we originally created this implementation. However, I believe a lot has still changed.
The writable streams label for the WHATWG streams specification doesn't show any major changes via closed issues. After chatting with @nicknisi briefly about an approach to this one, I'm going to go back through the spec itself to make sure everything is still covered using this diff as a basis (thanks, Nick!)
This manual approach may take some time, though, so any other suggestions to easily identify spec changes (for this spec or any others going forward) would be helpful.
I've been working to update our implementation to match the current spec here. It's slow progress; I've been focusing on API changes first and foremost, and I port over test changes, additions, and deletions where applicable. Ultimately, we'll need to write a test suite that fully hammers the spec, because the WHATWG tests are pretty limited and specific to their implementation.
For posterity, this diff shows the remaining commits we need to go through to get our implementation up to date.
I went through 50 more commits, updating our streams implementation to match the current spec. Current progress can be found here.
This diff now shows what's left. There's only 25 commits remaining, but the next one to dig through involves merging ReadableByteStream and ReadableStream, so it's essentially a rewrite of the latter. Did we ever decide that streams were a definite for Dojo 2? @kitsonk @dylans
We should consider breaking out stream from
To add to this, core/request/node depends on streams. It does not look trivial to decouple request/node's usage of streams (e.g. into a version that doesn't rely on streams, with streams perhaps extending the capabilities of the request when included.
So it may make sense to move request/node into the streams package, or put both into a core-server or core-node package, though streams may have a use client-side, so I don't really know what the right answer is, but it's not easy to unwind at this point (which was the main reason they were included in one package early on as they were originally separate).
If we can decide on how we should restructure things, I would be open to doing the refactoring work unless someone else wants to tackle it.
It is in there, but the architecture of
When #225 is finished, move this issue into new dojo/streams package.