Re: [w3ctag/design-reviews] WebTransport (#389)

@torgo and I are looking at this in a (second) breakout at the Tokyo face-to-face meeting.

One of the things we're talking about is the relationship between a bunch of different pieces of work that are ongoing.

If my understanding of what's going on is correct, it seems like WebSocketStream (see #394) is about designing a better (uses promises and streams, supports backpressure naturally) JavaScript API for the existing WebSocket protocol, and this work here is about designing a new network protocol (on top of a more modern substrate) and having a JavaScript API to go along with it.  One question in our minds is what the path for developers to use the various things is; it seems like in so far as WebSocketStream and WebTransport's JavaScript APIs are doing the same things, they ought to be able to work the same way, so that it's as easy as possible for developers to migrate from WebSocketStream (which we understand to be a shorter-term project) to WebTransport.  So, if this understanding is correct, we'd strongly encourage these JavaScript APIs to be developed in tandem.

That said, I'm not particularly confident of that understanding gleaned from across a bunch of different explainers and other documents, so we'd be interested to hear how it's wrong.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/389#issuecomment-530694381