Intent to Prototype and Ship: WebTransport BYOB readers

[Zhu, Jianjun]

Contact emails

jianj...@intel.com, ri...@chromium.org, nidh...@chromium.org

 

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

https://github.com/w3c/webtransport/issues/35

 

Specification

https://www.w3.org/TR/webtransport

https://streams.spec.whatwg.org/#readablestreambyobreader

 

Summary

Support BYOB(bring-your-own-buffer) readers for WebTransport to allow reading into a developer-supplied buffer. BYOB readers can minimize buffer copies, as well as reduce memory allocations.

 

This feature aligns blink implementation with the WebTransport spec (https://www.w3.org/TR/webtransport/#webtransportreceivestream-create). The underlying source of blink::IncomingStream and blink::DatagramDuplexStream are changed to UnderlyingByteSource to support this feature.

 

Blink component

Blink>Network>WebTransport

TAG review

https://github.com/w3ctag/design-reviews/issues/669

TAG review status

Not applicable

 

Risks

 

Interoperability and Compatibility

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/167)

WebKit: No signal

Web developers: No signals

Other signals:

Activation

Developers can acquire a BYOB reader by calling getReader({ mode: "byob" }) of a WebTransportDatagramDuplexStream.readable, or a WebTransportBidirectionalStream.readable, or a WebTransportReceiveStream.

 

WebView application risks

This feature doesn’t change the behaviors of exiting APIs. Calling getReader() without options returns a default reader.

 

Debuggability

This feature can be debugged with existing DevTools JavaScript debugger.

 

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?

Yes

 

Flag name

 

Requires code in //chrome?

False

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1259886

Sample links

https://github.com/w3c/webtransport/pull/415

Estimated milestones

108

 

Anticipated spec changes

No

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5948016536584192

This intent message was generated by Chrome Platform Status.

 

[Mike Taylor]

Hi there,

On 10/7/22 8:27 AM, Zhu, Jianjun wrote:

Contact emails

jianj...@intel.com, ri...@chromium.org, nidh...@chromium.org

 

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

https://github.com/w3c/webtransport/issues/35

Are these the correct links? It seems to be about webtransport in general, and I'm not sure how to interpret issue 35 (likely I'm just missing a lot of context). Is there something close to an explainer for BYOB readers?

Specification

https://www.w3.org/TR/webtransport

https://streams.spec.whatwg.org/#readablestreambyobreader

 

Summary

Support BYOB(bring-your-own-buffer) readers for WebTransport to allow reading into a developer-supplied buffer. BYOB readers can minimize buffer copies, as well as reduce memory allocations.

 

This feature aligns blink implementation with the WebTransport spec (https://www.w3.org/TR/webtransport/#webtransportreceivestream-create). The underlying source of blink::IncomingStream and blink::DatagramDuplexStream are changed to UnderlyingByteSource to support this feature.

 

Blink component

Blink>Network>WebTransport

TAG review

https://github.com/w3ctag/design-reviews/issues/669

TAG review status

Not applicable

 

Risks

 

Interoperability and Compatibility

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/167) WebKit: No signal Web developers: No signals

Could we request a WebKit signal please? Do we have any signals from developers?

Other signals:

Activation

Developers can acquire a BYOB reader by calling getReader({ mode: "byob" }) of a WebTransportDatagramDuplexStream.readable, or a WebTransportBidirectionalStream.readable, or a WebTransportReceiveStream.

 

WebView application risks

This feature doesn’t change the behaviors of exiting APIs. Calling getReader() without options returns a default reader.

 

Debuggability

This feature can be debugged with existing DevTools JavaScript debugger.

 

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?

Yes

Could you link to the wpt.fyi link please?

 

Flag name

 

Requires code in //chrome?

False

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1259886

Sample links

https://github.com/w3c/webtransport/pull/415

Estimated milestones

108

 

Anticipated spec changes

No

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5948016536584192

This intent message was generated by Chrome Platform Status.

 

--
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/PH0PR11MB488707A531780543D97765FBFB5F9%40PH0PR11MB4887.namprd11.prod.outlook.com.

[jianj...@intel.com]

Hi Mike,

Thanks for your review. Below are answers for your questions.

Q: Are these the correct links? It seems to be about webtransport in general, and I'm not sure how to interpret issue 35 (likely I'm just missing a lot of context). Is there something close to an explainer for BYOB readers?

A: The first link is the explainer for WebTransport in general. The explainer was updated by issue 35 to include the use of WHATWG streams. WHATWG streams spec defines BYOB readers. The link to issue 35 was added here to provide some information about how the WG decided to use WHATWG streams.

Q: Could we request a WebKit signal please? Do we have any signals from developers?

A: This is the link for WebKit's position on WebTransport. It looks like it's still no signal yet.

For web developers, based on the discussion of issue 35, issue 131, and the comment from Divyanshu in this CL. I would like to consider it as positive. But I'm not sure if the evidence is strong enough.

Q: Could you link to the wpt.fyi link please?

A: Link to wpt.fyi: https://wpt.fyi/results/webtransport/streams-echo.https.any.html?label=experimental&label=master&aligned (last 2 cases). Some new cases will be added in this CL as well.

[Alex Russell]

LGTM1, but in future would be great to see a reason cited for why the omnibus TAG review applies to this specific sub-feature.

[Yoav Weiss]

LGTM2

[Mike Taylor]

LGTM3

[jianj...@intel.com]

Thanks for your review.

The link is the 2nd TAG review for WebTransport. Major changes since last review are summaries in this comment. Item 6,7,8,9 are related to WHATWG streams. This feature aligns blink implementation with these changes.

[Mike Taylor]

LGTM2

[Mike Taylor]

(I can't count... that should be LGTM3)