On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhir...@chromium.org> wrote:
> Hi Philip, > > Sorry for the belated reply. Comments inline: > > On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> > wrote: > >> Hi again, >> >> I've made a full pass of the intent now. I have a lot of questions, but >> am pretty convinced we should ship this, it's just a matter of what things >> need to block that, and what things can be left until later. >> >> Comments inline... >> >> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhir...@chromium.org> >> wrote: >> >>> Contact emails >>> >>> yhir...@chromium.org, vasi...@chromium.org >>> >>> Explainer >>> >>> https://github.com/w3c/webtransport/blob/main/explainer.md >>> >>> Specification >>> >>> https://w3c.github.io/webtransport >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/ >>> >> >> I skimmed https://github.com/w3c/webtransport/issues/ and see multiple >> issues filed by other browser vendors. Are any of the remaining issues ones >> that could change the API's shape or behavior? It would be good to resolve >> any such issues, since they won't be possible to address once the API is >> locked in by sites depending on it. >> >> > I believe we've addressed issues that may require breaking changes. You > can see open <https://github.com/w3c/webtransport/milestone/1>/closed > <https://github.com/w3c/webtransport/milestone/1?closed=1> issues for the > initial launch (this intent). I shared our plan > <https://docs.google.com/document/d/1X9-a03rtm0FqTW01nG6e7f91NAguGEv37mP964HrJlk/edit#heading=h.v9yxozj8naro> > at a WG meeting in May > <https://www.w3.org/wiki/WebTransport/Meetings#WebTransport_Bi-weekly_Virtual_Meeting_.2316_late_-_May_25.2C_2021> > and > we've been working to find and resolve such issues since then. > I see, creating a milestone for this is really handy! Are the remaining issue in https://github.com/w3c/webtransport/milestone/1 not blocking then, even issue #349 <https://github.com/w3c/webtransport/issues/349>? Activation >>> >>> Since UDP is often blocked on the network, the developers have to assume >>> that the API often would not work even in the situations when it is >>> implemented in the browser. >>> >> >> This is interesting. How do web developers detect and deal with this >> situation, and distinguish it from the network temporarily going down? I've >> skimmed https://web.dev/webtransport/ and it doesn't mention this kind >> of blocking, does this need to be highlighted in documentation and >> reference docs for WebTransport? >> > > For usual loading browsers detect the network conditions and choose the > right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar > things in the future (on the other hand, we may end up asking web > developers to detect it). Some people are working on WebTransport over > HTTP/2 <https://github.com/ietf-wg-webtrans/draft-webtransport-http2>. > With the implementation as it is now, what will the behavior be on a network where UDP is blocked? Presumably the initial connection that serves HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is there any indication in the API that WebTransport is going to fail ahead of time, or error that can be distinguished from an intermittent network error? I'm thinking of the code to fall back to WebSockets that might be necessary here, how one would determine that the fallback is needed. Speaking of reference docs... Getting a feature documented on MDN isn't >> part of the Blink launch process, but are you working with anyone to get it >> documented by the time the feature reaches Chrome stable? >> >> > I haven't talked with anyone. Do you have a good idea? > As I said this isn't a required part of the launch process, but +Joe Medley <jmed...@google.com> knows the documentation process very well. Joe, where would you suggest to start in order to ensure a feature becomes documented on MDN around the time it reaches stable? -- 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/CAARdPYeOwNUPUcG1eREVNXQDzKk24yXWmMQRcp4rNZx9mRDfGw%40mail.gmail.com.
