That's right. Best regards, Byron Campen
On 9/6/17 1:30 PM, Tom Ritter wrote:
IIRC, the rework won't be able to be switched 'back-to-existing' with a pref, but we'll continue to respect existing disable-webrtc prefs and the --disable-webrtc compiler switch, right? -tom On Wed, Sep 6, 2017 at 11:41 AM, Byron Campen <[email protected]> wrote:What: RTCRtpTransceiver is a central part of the w3c webrtc API (https://www.w3.org/TR/webrtc/) and JSEP spec (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep). This is a significant addition to the webrtc API, and entails a rework of the internals (it is not practical to hide this rework code behind a pref). This work will apply to all platforms and in all situations where RTCPeerConnection is supported now. Why: This has been in the relevant specifications for a year and a half, is considered "done" from a spec perspective, but still hasn't been implemented. Given that this spec involves browser-to-browser interop, it is vital that there be some running code out there. Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1290948 When: My intent is to land this early in the 58 release cycle. Our existing test suite will do a good job of covering the internal rework, and I have written some additional test-cases to cover the new API. web-platform-tests has some coverage of the new API also (in https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-addTransceiver.html and https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-getTransceivers.html). Best regards, Byron Campen _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
