LGTM2.

On Fri, Aug 9, 2024 at 8:22 AM Thomas Guilbert <tguilb...@chromium.org>
wrote:

> Contact emailstguilb...@chromium.org
>
> ExplainerNone
>
> Specification
> https://w3c.github.io/webrtc-extensions/#rtcdatachannel-transferable
>

This is a fine specification for shipping the feature. But it's a bit sad
that it's a monkey patch specification
<https://annevankesteren.nl/2014/02/monkey-patch> for a feature that it
sounds like everyone agrees on.

The Web RTC Extensions specification says "As extensions mature and gain
implementation experience, they may move from this document to the base
specification if WG consensus emerges to do so." Do you know if there's any
effort to merge this monkey patch into the base specification?


>
>
> Summary
>
> The RTCDataChannel interface is part of the WebRTC standard, and
> represents a network channel which can be used for bidirectional
> peer-to-peer transfers of arbitrary data. This feature tracks exposing
> RTCDataChannel in dedicated workers, and allowing the transfer of
> RTCDataChannels to them workers. This will help reduce main thread
> contention and lead to smoother and more reliable WebRTC applications.
>
>
> Blink componentBlink>WebRTC>DataChannel
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3EDataChannel>
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is an interoperability risk when it comes to which types of workers
> are supported by which browser. - Safari/WebKit supports transfers to
> DedicatedWorkers and to ServiceWorkers. - Chromium is only looking to add
> transfers to DedicatedWorkers; supporting transfers to ServiceWorkers would
> require significant architectural changes (across processes, rather than
> across threads) and might never be supported. - Firefox/Gecko supports
> neither, but might support transfers to both DedicatedWorkers and
> ServiceWorkers, if/when they choose to support this feature. Regardless of
> whether or not Chromium supports transfers to ServiceWorkers, enabling
> transfers to DedicatedWorkers addresses current developer needs, and
> improves interoperability.
>
>
> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1209163)
> Mozilla is aware of the issue, but has not allocated resources to it as of
> yet.
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=222965
> )
>
> *Web developers*: Positive This has been a longstanding request from
> developers. E.g: https://bugzilla.mozilla.org/show_bug.cgi?id=1209163#c4
> https://issues.chromium.org/issues/40787712#comment21
>
> *Other signals*:
>
> Ergonomics
>
> This feature improves the ergonomics of existing Worker exposed APIs. For
> example, it allows developers to use WebCodecs and Offscreen canvas from
> workers, without having to repeatedly transfer data from the main thread.
>
>
> Activation
>
> N/A
>
>
> Security
>
> This feature should not introduce any new security risks. Existing risks
> can be found in the WebRTC API specification:
> https://w3c.github.io/webrtc-pc/#privacy-and-security-considerations
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Yes
>
> DedicatedWorkers:
> https://wpt.fyi/results/webrtc-extensions/transfer-datachannel.html?label=experimental&label=master&aligned
> ServiceWorkers (out of scope for this feature):
> https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameTransferableRTCDataChannel
>
> Requires code in //chrome?False
>
> Sample links
> https://tguilbert-google.github.io/RTCDataChannel/index.html
>
> Estimated milestones
> Shipping on desktop 130
> DevTrial on desktop 129
> Shipping on Android 130
> DevTrial on Android 129
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6612726584180736?gate=4885503741263872
>
> Links to previous Intent discussionsIntent to Prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dab53bcd-e51d-41bc-a312-4bd3e08322f0n%40chromium.org
>
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
>
> --
> 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/CABrVPoba%2B6EuYDdfxKF8ZXn%3DXmzt6vd1tZ53yTS9-CEdUBXTzw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoba%2B6EuYDdfxKF8ZXn%3DXmzt6vd1tZ53yTS9-CEdUBXTzw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAM0wra_MUXCsrpODkCarYj%3DY7%2BDipq0mX_dcY44auGzV-QZ7Qw%40mail.gmail.com.

Reply via email to