Discussing amongst the API owners (Alex, Daniel, Rego and myself), this is essentially a request for a gapless OT, only that the would-be-gap is slightly longer than usual. Given the evidence <https://groups.google.com/a/chromium.org/g/blink-dev/c/kwC5wES3I4c/m/2WxYhllhAAAJ?utm_medium=email&utm_source=footer> of developer feedback presented in the I2S, that seems like a reasonable request.
LGTM1 (as gapless OT requests require 3 LGTMs) On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote: > Contact emails > > yhir...@chromium.org,vasi...@chromium.org > > Explainer > > https://github.com/w3c/webtransport/blob/main/explainer.md > > Design docs/spec > > Specification: https://w3c.github.io/webtransport/#web-transport > > > https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit > > TAG review > > https://github.com/w3ctag/design-reviews/issues/669 > > > Summary > > WebTransport is an interface representing a set of reliable/unreliable > streams to a server. The interface potentially supports multiple protocols, > but based on discussions on the IETF webtrans working group, we are > developing WebTransport over HTTP/3 which uses HTTP3 as the underlying > protocol. > > Note that we were developing QuicTransport a.k.a. WebTransport over QUIC > and we ran an origin trial M84 through M90. It uses the same interface > WebTransport, but because of the protocol difference ("quic-transport" vs. > "https") it is difficult for web developers to be confused by them. > > new WebTransport("quic-transport://example.com:9922") > > represents a WebTransport over QUIC connection, and > > new WebTransport("https://example.com:9922";) > > represents a WebTransport over HTTP/3 connection. > > Goals for experimentation > > We're shipping the API in M97 > <https://groups.google.com/a/chromium.org/g/blink-dev/c/kwC5wES3I4c/m/2WxYhllhAAAJ>. > > Twitch, one of our partners, wants to continue their experiment until the > API is fully shipped. I think this is a reasonable request given we > originally aimed to ship the feature in M96 but we missed the branch point. > > > The original goals follow: > > > To see whether the API (and the implementation) is useful in various > circumstances. > > Our partners want to evaluate this API on various network circumstances > (i.e., lab environments are not enough) to see its effectiveness. > > We also expect feedback for performance. > > Experimental timeline > > M95 and M96 > > Ongoing technical constraints > > None > > Debuggability > > The devtools support is under development. > > Just like with regular HTTP/3 traffic, the detailed information about the > connection can be obtained via chrome://net-export interface. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, > > Chrome OS, Android, and Android WebView)? > > Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > No > > We have browser tests, but we are going to port them to WPT. > > Link to entry on the Chrome Platform Status > > https://www.chromestatus.com/feature/4854144902889472 > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org.
