Intent to Experiment: WebTransport over HTTP/3

1,465 बार देखा गया
नहीं पढ़े गए पहले मैसेज पर जाएं

Yutaka Hirano

नहीं पढ़ी गई,
12 अप्रैल 2021, 6:15:16 am12/4/21
ईमेल पाने वाला blink-dev, web-transport-dev

Contact emails

yhi...@chromium.org,vas...@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/389



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

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

M91-M95


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?

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

Yutaka Hirano

नहीं पढ़ी गई,
14 अप्रैल 2021, 5:51:11 am14/4/21
ईमेल पाने वाला guest271314, web-transport-dev, blink-dev
Hi,

On Wed, Apr 14, 2021 at 10:19 AM guest271314 <guest...@gmail.com> wrote:
> 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.

I am not confused by quic-transport protocol.

blob: file:, other protocol exist. 


I would suggest to not removed quic-transport, given there is no comparable HTTP/3 working code for WebTransport that I am aware of https://github.com/aio-libs/aiohttp/discussions/5581#discussioncomment-570522.

For those already using the quic-transport protocol, consider only removing quic-transport once there is working server code to substitute for the working Python aioquic server code.


At this moment I *believe* WebTransport over QUIC is still working - we haven't deleted the code yet. But we are doing that soonish.
 
> vs. "https"

We may as well just use fetch()?


I'm not sure if I understand this question.
Please refer to the IETF working group discussions for the protocol selection.

 
> Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness.

Some experiments using quic-transport protocol to stream STDOUT from espeak-ng to work around Web Speech API and Media Capture and Streams (getUserMedia()) and Screen Capture (getDisplayMedia()) not supporting capture of window.speechSynthesisSpeak(), and Web Speech API not supporting SSML input or parsing option passed to Speech Dispatcher (including usage of Media Transform API) therewith


I am willing to test (media streaming; etc.) at the front end.

Yoav Weiss

नहीं पढ़ी गई,
15 अप्रैल 2021, 12:43:21 pm15/4/21
ईमेल पाने वाला blink-dev, Yutaka Hirano, web-transport-dev, blink-dev, guest271314

Any learnings from the OT with QUIC that led you to try WebTransport over H3?

Bernard Aboba

नहीं पढ़ी गई,
15 अप्रैल 2021, 8:35:20 pm15/4/21
ईमेल पाने वाला Luke Curley, Yoav Weiss, blink-dev, Yutaka Hirano, web-transport-dev, guest271314
One learning was that client/server QuicTransport was converging toward Http3Transport to address security issues. So having 2 client/server protocols was hard to justify.

The learning from the previous OT was that P2P QuicTransport was preferred over client server in gaming and remote desktop use cases (removing ICE was considered a bug, not a feature). P2P QUIC performed better than RTCDatachannel for reliable streams but for gaming and remote desktop use cases partial or unreliable transport was required and there the perf advantage was not as great, nor did QUIC datagrams do any better in terms of backpressure (needed to be handled at the app layer anyway). 


--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/6a93c6e5-5dc2-43b0-bada-16bc890f40bfn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CAHVo%3DZ%3DLrbufoo7L7mWp-HcPszX%3DkO65pRHWVaScDBWy-U3dZA%40mail.gmail.com.

Yutaka Hirano

नहीं पढ़ी गई,
16 अप्रैल 2021, 3:14:01 am16/4/21
ईमेल पाने वाला Bernard Aboba, Luke Curley, Yoav Weiss, blink-dev, web-transport-dev, guest271314
In addition to the experiment Twitch is running, Zoom also used our WebTransport over QUIC prototype and provided a feedback (https://groups.google.com/a/chromium.org/g/web-transport-dev/c/EqQodC2V50U/m/fU0RsCoYAQAJ).
It led us to specify a few options in the spec (https://github.com/w3c/webtransport/issues/152).

Thanks,

Yoav Weiss

नहीं पढ़ी गई,
16 अप्रैल 2021, 3:29:08 am16/4/21
ईमेल पाने वाला Yutaka Hirano, Bernard Aboba, Luke Curley, blink-dev, web-transport-dev, guest271314
Great learnings, thanks for sharing all!

LGTM to experiment M91-95

guest271314

नहीं पढ़ी गई,
16 अप्रैल 2021, 7:18:58 pm16/4/21
ईमेल पाने वाला web-transport-dev, yhi...@chromium.org, blink-dev
> 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.

I am not confused by quic-transport protocol.

blob: file:, other protocol exist. 


I would suggest to not removed quic-transport, given there is no comparable HTTP/3 working code for WebTransport that I am aware of https://github.com/aio-libs/aiohttp/discussions/5581#discussioncomment-570522.

For those already using the quic-transport protocol, consider only removing quic-transport once there is working server code to substitute for the working Python aioquic server code.

> vs. "https"

We may as well just use fetch()?

> Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness.

Some experiments using quic-transport protocol to stream STDOUT from espeak-ng to work around Web Speech API and Media Capture and Streams (getUserMedia()) and Screen Capture (getDisplayMedia()) not supporting capture of window.speechSynthesisSpeak(), and Web Speech API not supporting SSML input or parsing option passed to Speech Dispatcher (including usage of Media Transform API) therewith


I am willing to test (media streaming; etc.) at the front end.






On Monday, April 12, 2021 at 3:15:09 AM UTC-7 yhi...@chromium.org wrote:

guest271314

नहीं पढ़ी गई,
16 अप्रैल 2021, 7:19:14 pm16/4/21
ईमेल पाने वाला web-transport-dev, yhi...@chromium.org, web-transport-dev, blink-dev, guest271314
I read the IETF working group discussions for the protocol selection.

quic-transport protocol is not confusing one way or the other , here, re this document.

My request is simple: Kindly substitute working HTTP/3 server code for working Python aioquic server code at Google sample before removing quic-transport from Chrome source code. I am still on 

Chromium

91.0.4458.0 (Developer Build) (64-bit)
Revision

e6fc042e9d532f8c1d223301495d2919e3da5a2c-refs/heads/master@{#866361}

I noted some additions and modification in recent bugs re WebTransport. I am not sure if the protocol is still there. I know the code I use works now with quic-transport over WebTransport and QuicTransport.

Re fetch() - given the vote was to use HTTPS, why would developers not just use fetch() instead of WebTransport - in case IETF working group decide to change their minds again and remove working code?

Thanks for this technology, again. 

Luke Curley

नहीं पढ़ी गई,
16 अप्रैल 2021, 7:19:30 pm16/4/21
ईमेल पाने वाला guest271314, web-transport-dev, yhi...@chromium.org, blink-dev
To clarify, Http3Transport and QuicTransport both offer the same WebTransport API and functionality. It requires more code to support HTTP/3 (primarily QPACK) but the IETF working group felt it was important to converge on one transport instead of two.

Http3Transport uses a HTTP request (CONNECT) while QuicTransport uses a custom handshake on the first QUIC stream. Once the session has been established, both expose the underlying QUIC connection as the WebTransport API. So Http3Transport uses HTTP/3 just for the handshake while QUIC is used for everything else.

Twitch is using QuicTransport and we'll be the first to try out Http3Transport when it's available.

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.

Luke Curley

नहीं पढ़ी गई,
16 अप्रैल 2021, 7:20:14 pm16/4/21
ईमेल पाने वाला Yoav Weiss, blink-dev, Yutaka Hirano, web-transport-dev, guest271314
Hey Yoav, not sure if that question was directed at me, but I'll answer it anyway!

We've built an application using QuicTransport, utilizing a server that pushes and prioritizes QUIC streams based on importance. Prioritization is possible using WebSockets, but just like HTTP/2 it suffers from TCP head-of-line blocking. We've had to work around a few bugs with QuicTransport but it's fundamentally the best browser-supported protocol for our use-case.

We'll be using WebTransport over H3 because it offers the same functionality but with a different handshake. It would be unfortunate if WebTransport fails to be adopted and we would fallback to a slightly worse approach that uses HTTP/3.

On Thu, Apr 15, 2021 at 9:43 AM Yoav Weiss <yoav...@chromium.org> wrote:
--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.

Dana Tyler

नहीं पढ़ी गई,
16 अप्रैल 2021, 7:20:36 pm16/4/21
ईमेल पाने वाला Yoav Weiss, Yutaka Hirano, Bernard Aboba, Luke Curley, blink-dev, web-transport-dev, guest271314
Thanks

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX_XjA%3Do49Qk06Apq-pa41dv9%2BHPXnbM%3DHbLQgAGE7WXg%40mail.gmail.com.

guest271314

नहीं पढ़ी गई,
3 मई 2021, 11:43:26 am3/5/21
ईमेल पाने वाला web-transport-dev, guest271314, Luke Curley, web-transport-dev, yhi...@chromium.org, blink-dev
My use case for QuicTransport/WebTransport is not necessarily based on networking, rather a substitute for using a browser extension and Native Messaging (which has limitations re streaming; cannot really use Transferable Streams between extension and browser at console at an arbitrary page) to execute arbitrary local native applications and shell scripts, streaming STDOUT therefrom to browser. 

I filed this FUGU https://bugs.chromium.org/p/chromium/issues/detail?id=1115640 before experimenting with QuicTransport, which effectively achieves the requirement - save for the inability to run the code at console at arbitrary web page due to CORS and/or CSP restrictions - otherwise works as intended for the use case of getting output of espeak-ng as WAV piped to browser then output using Media Capture Transform MediaStreamTrackGenerator or Web Audio API AudioWorklet - to work around the fact that there is no API to 1) capture audio output of Web Speech API (https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html); 2) pass an option to speech-dispatcher to interpret input as SSML (speech synthesis markup language) (https://github.com/guest271314/SSMLParser) .

I do not need "pooling". 

TL;DR As soon as I got this working you folks removed the functionaility without a working replacement or substitute.



On Saturday, May 1, 2021 at 9:19:35 PM UTC guest271314 wrote:
Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

guest271314

नहीं पढ़ी गई,
3 मई 2021, 11:44:44 am3/5/21
ईमेल पाने वाला blink-dev, Luke Curley, web-transport-dev, yhi...@chromium.org, blink-dev, guest271314
Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

On Friday, April 16, 2021 at 11:19:30 PM UTC Luke Curley wrote:

Yutaka Hirano

नहीं पढ़ी गई,
6 मई 2021, 5:56:25 am6/5/21
ईमेल पाने वाला guest271314, web-transport-dev, Luke Curley, blink-dev
On Sun, May 2, 2021 at 11:16 PM guest271314 <guest...@gmail.com> wrote:
My use case for QuicTransport/WebTransport is not necessarily based on networking, rather a substitute for using a browser extension and Native Messaging (which has limitations re streaming; cannot really use Transferable Streams between extension and browser at console at an arbitrary page) to execute arbitrary local native applications and shell scripts, streaming STDOUT therefrom to browser. 

I filed this FUGU https://bugs.chromium.org/p/chromium/issues/detail?id=1115640 before experimenting with QuicTransport, which effectively achieves the requirement - save for the inability to run the code at console at arbitrary web page due to CORS and/or CSP restrictions - otherwise works as intended for the use case of getting output of espeak-ng as WAV piped to browser then output using Media Capture Transform MediaStreamTrackGenerator or Web Audio API AudioWorklet - to work around the fact that there is no API to 1) capture audio output of Web Speech API (https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html); 2) pass an option to speech-dispatcher to interpret input as SSML (speech synthesis markup language) (https://github.com/guest271314/SSMLParser) .

I do not need "pooling". 

TL;DR As soon as I got this working you folks removed the functionaility without a working replacement or substitute.

Sorry for the inconvenience. We decided to focus on WebTransport over HTTP/3 in January at the IETF working group, and I should have announced our plan earlier.
As I stated before, "Please note that the API is not at all final, and we will make further changes. But we'll do our best to minimize your pain when we update the API." This is still true, and this applies to the protocol too.
 


On Saturday, May 1, 2021 at 9:19:35 PM UTC guest271314 wrote:
Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

We're using a simple server on our browser tests.

 

guest271314

नहीं पढ़ी गई,
18 मई 2021, 11:42:37 am18/5/21
ईमेल पाने वाला blink-dev, Yutaka Hirano, web-transport-dev, Luke Curley, blink-dev, guest271314
> We're using a simple server on our browser tests.


My particular use case is running local applications and shell scripts at console on any origin and getting STDOUT streamed to browser in "real-time". Something like what is described at https://github.com/httpslocal/proposals/issues/2. That can be achieved using several existing technologies already existing in Chrome/Chromium source code. Unfortunately QuicTransport was deprecated, the focus here is on networking alone, while this technology is capable of solving longstanding issues other than networking in Chrome/Chromium, a bried synpopsis of those issues and what WebTransport can remedy is described at https://groups.google.com/a/chromium.org/g/chromium-extensions/c/BnsgStmVOMc.

It would be helpful to users in the field if the server and browser test code used here be updated at https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/, if that is possible. The current quic-transport code is obsolete, and the repository has Google's name on it.

Due to focus on HTTP/3 which is under CSP I am not certain if using WebTransport will be any different than using a Chrome extension and fetch() to stream STDOUT.

I look forward to the further development of WebTransport nonetheless.

Kind regards,
/guest271314/

Yutaka Hirano

नहीं पढ़ी गई,
2 जून 2021, 3:08:34 am2/6/21
ईमेल पाने वाला 刘连响, web-transport-dev, Luke Curley, blink-dev, guest...@gmail.com
Sorry, the test server is for QuicTransport, and we've switched the protocol since then.

Currently we're using a WebTransport over HTTP/3 server for testing, but using the server is not easy I think.
We're working to build a WebTransport over HTTP/3 server for web-platform-test, and that server will be easier to use/extend.

On Wed, Jun 2, 2021 at 3:58 PM 刘连响 <not...@gmail.com> wrote:
The  https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport can not works now,   Is there any working demo with the latest WebTransport?

刘连响

नहीं पढ़ी गई,
2 जून 2021, 10:25:32 am2/6/21
ईमेल पाने वाला web-transport-dev, yhi...@chromium.org, web-transport-dev, Luke Curley, blink-dev, guest...@gmail.com
The  https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport can not works now,   Is there any working demo with the latest WebTransport?

在2021年5月6日星期四 UTC+8 下午5:56:20<yhi...@chromium.org> 写道:

Luke Curley

नहीं पढ़ी गई,
4 जून 2021, 5:05:42 pm4/6/21
ईमेल पाने वाला Yutaka Hirano, 刘连响, web-transport-dev, blink-dev, guest...@gmail.com
We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

Victor Vasiliev

नहीं पढ़ी गई,
5 जून 2021, 12:07:28 am5/6/21
ईमेल पाने वाला guest271314, web-transport-dev, Luke Curley, not...@gmail.com, blink-dev, yhi...@chromium.org
For what it's worth, I don't believe there are any meaningful parts of Google's WebTransport implementation that are not already open source; we do have a test server written in C++ that is a part of Chromium, though it's not very well-documented nor is it really that useful (I think it only implements echo operations).

Regarding the example code, it will most likely be updated to HTTP/3-based WebTransport relatively soon, though I can't give an exact timeline for that yet.

On Fri, Jun 4, 2021 at 8:27 PM guest271314 <guest...@gmail.com> wrote:
> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

guest271314

नहीं पढ़ी गई,
5 जून 2021, 5:43:09 pm5/6/21
ईमेल पाने वाला web-transport-dev, Luke Curley, web-transport-dev, not...@gmail.com, blink-dev, yhi...@chromium.org, guest271314
You mentioned large company. The same principle applies whatever the brand is, or the specification body that write up this stuff. What is the mission statement and priority, FOSS or profit? The result of that inquiry is observable in real-time. 

>  I can help if anybody has any questions or runs into issues.

I began this discussion in aio-http https://github.com/aio-libs/aiohttp/discussions/5581 

> aiohttp does only supports HTTP/1.1. To support HTTP/2 and HTTP/3 somebody needs to step in and actually implement it. 

because I finally got the Python code working while learning Python by doing. It would be, perhaps, useful for developers in the field who were running the Google samples server code to have similar Python HTTP/3 code. Or, any language server code, if you are involved with the inner mechanics of this efforet, big company, small company, individual, does not matter. Publish your tests for users in the field to test. You cannot gather all information in a closed-loop system, even if the group thinks they can, they cannot prove anything from only within, Godel proved that mathematically some time ago.

For now I am using fetch() to achieve the requirement of streaming STDOUT from shell script, to for example, stream speech synthesis and media, and PHP passthru() on the server side. I look forward to furhter experimenting with WebTransport. Thanks for your feedback.

On Friday, June 4, 2021 at 6:19:48 PM UTC-7 Luke Curley wrote:
To be clear, I don't work at Google nor do I work on Chromium. I agree that it would have been much easier to implement WebTransport with a sample server. I'm planning on releasing my QUIC + WebTransport implementation anyway but it will take a bit of time.

Fortunately, the spec is relatively simple and mostly involves supporting a few new stream/frame types at the HTTP/3 layer. I can help if anybody has any questions or runs into issues.


On Fri, Jun 4, 2021, 5:27 PM guest271314 <guest...@gmail.com> wrote:
> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

Luke Curley

नहीं पढ़ी गई,
5 जून 2021, 5:43:18 pm5/6/21
ईमेल पाने वाला guest271314, web-transport-dev, not...@gmail.com, blink-dev, yhi...@chromium.org
To be clear, I don't work at Google nor do I work on Chromium. I agree that it would have been much easier to implement WebTransport with a sample server. I'm planning on releasing my QUIC + WebTransport implementation anyway but it will take a bit of time.

Fortunately, the spec is relatively simple and mostly involves supporting a few new stream/frame types at the HTTP/3 layer. I can help if anybody has any questions or runs into issues.

On Fri, Jun 4, 2021, 5:27 PM guest271314 <guest...@gmail.com> wrote:
> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

guest271314

नहीं पढ़ी गई,
5 जून 2021, 5:43:37 pm5/6/21
ईमेल पाने वाला web-transport-dev, Luke Curley, not...@gmail.com, web-transport-dev, blink-dev, guest271314, yhi...@chromium.org
> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

Yoav Weiss

नहीं पढ़ी गई,
7 जून 2021, 12:39:36 am7/6/21
ईमेल पाने वाला guest271314, web-transport-dev, Luke Curley, not...@gmail.com, blink-dev, yhi...@chromium.org
guest271314@ - I urge you to tone it down. 

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e08ab0e1-97ab-4a94-bb28-dec353aa4c68n%40chromium.org.

guest271314

नहीं पढ़ी गई,
7 जून 2021, 11:10:24 am7/6/21
ईमेल पाने वाला blink-dev, yoav...@chromium.org, web-transport-dev, Luke Curley, not...@gmail.com, blink-dev, yhi...@chromium.org, guest271314
> guest271314@ - I urge you to tone it down. 

I do not understand what you mean. Be specific. If you do not want feedback from me just say that. Don't infer.

Ban me for another 1,000 years for pointing out that the cart is before the horse re deprecation of QuicTransport before WebTransport over HTTP/3 is operational?

Yoav Weiss

नहीं पढ़ी गई,
7 जून 2021, 11:19:36 am7/6/21
ईमेल पाने वाला guest271314, blink-dev, web-transport-dev, Luke Curley, not...@gmail.com, yhi...@chromium.org
On Mon, Jun 7, 2021 at 8:22 AM guest271314 <guest...@gmail.com> wrote:
> guest271314@ - I urge you to tone it down. 

I do not understand what you mean. Be specific. If you do not want feedback from me just say that. Don't infer.

I specifically ask to use a calm and respectful tone when talking to other folks in this forum. The example that triggered my comment is Luke providing useful feedback on this thread, and you responding aggressively because they cannot share the relevant code. 


Ban me for another 1,000 years

I'd prefer it if you could provide your feedback in a calm, respectful and constructive manner, according to our code of conduct.
 
for pointing out that the cart is before the horse re deprecation of QuicTransport before WebTransport over HTTP/3 is operational?

IIUC, QuicTransport was in an Origin Trial and never shipped. As such, there's no need for a replacement before changing the implementation or trying out a different API shape.
सभी को जवाब दें
ईमेल भेजने वाले को जवाब दें
आगे भेजें
0 नया मैसेज