Intent to Implement and Ship: Promise-based RTCPeerConnection's createOffer and createAnswer methods.

539 weergaven
Naar het eerste ongelezen bericht

Guido Urdaneta

ongelezen,
29 feb. 2016 09:27:5829-02-2016
aan blink-dev

Contact emails

gui...@chromium.org, h...@chromium.org


Spec

https://w3c.github.io/webrtc-pc/

Tag review: https://github.com/w3ctag/spec-reviews/issues/14


Summary

The latest version of the WebRTC spec introduces five new promise-based versions of existing RTCPeerConnection methods.

This intent covers the addition of two three of these methods: createOffer() and createAnswer(). Promise-based versions of the other three methods (setLocalDescription(), setRemoteDescription() and addIceCandidate()) already exist in Blink. See related Intent to Ship thread.

Promise-based versions of createOffer() and createAnswer(), are being added one release after the other methods because there were overloading issues in the legacy versions of createOffer() and createAnswer() that required a stabilization period to be resolved (see related Intent to Remove thread).


Motivation

The WebRTC API, like many other JavaScript APIs, has been updated to support promises instead of callbacks as the preferred mechanism for asynchronous programming. This Intent to Ship is a step in that direction. Existing callback-based code will continue to be supported, though.


Interoperability and Compatibility Risk

The addition of these three new methods improves interoperability, as it makes Blink more compliant with the spec and more compatible with Firefox, which already supports these methods. In addition, the existing versions of the methods are still supported, so existing applications do not need to be rewritten.


The main compatibility issue this change introduces is that the return type of legacy methods will change from void to Promise<void>. In practice, this means that TypeErrors will not be thrown as usual, but will be reported to the returned Promise. This can happen when the methods are invoked with arguments of incorrect types. The current legacy implementations of createOffer() and createAnswer() also throw TypeErrors  when custom parsing of one of the arguments fails. This implementation detail will be changed so that some harmless errors (e.g., the presence of an unused field) do not result in a failure, or that parsing errors are reported via the failure callback.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

crbug.com/582920.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5743313768415232


Requesting approval to ship?

Yes.


Philip Jägenstedt

ongelezen,
29 feb. 2016 12:31:3729-02-2016
aan Guido Urdaneta, blink-dev
LGTM1. Guido and I are discussing some of the details for errors in custom dictionary parsing in https://codereview.chromium.org/1713953002/, but that's all with the goal of enabling the promise-based methods.

--
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.

Chris Harrelson

ongelezen,
1 mrt. 2016 11:29:0301-03-2016
aan Philip Jägenstedt, Guido Urdaneta, blink-dev
LGTM2

TAMURA, Kent

ongelezen,
1 mrt. 2016 20:45:4601-03-2016
aan Chris Harrelson, Philip Jägenstedt, Guido Urdaneta, blink-dev
LGTM3

--
TAMURA Kent
Software Engineer, Google


PhistucK

ongelezen,
13 jun. 2016 11:45:4713-06-2016
aan TAMURA, Kent, Chris Harrelson, Philip Jägenstedt, Guido Urdaneta, blink-dev
As it turns out, the new Promise based createOffer method comes with a new addTransceiver() method which was not implemented and thus creates some compatibility and/or interoperability issue.
See crbug.com/619289#c5 for details.

Harald says -
"the only question is how much pushback we get on adding non-standard options to the Web-exposed API"


PhistucK

PhistucK

ongelezen,
8 jul. 2017 04:10:0508-07-2017
aan Harald Alvestrand, Guido Urdaneta, blink-dev, Philip Jägenstedt
WebKit advocates addTransceiver as well now in their recently revealed implementation.

Are there any short-term plans to implement it before Safari 11 is released?
I see that no other browser implemented this API (except the upcoming Safari 11) -

If there are no plans to implement this method, perhaps WebKit/Safari 11 should remove it as well?




PhistucK



PhistucK

LGTM3


LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.



--
TAMURA Kent
Software Engineer, Google


--
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+unsubscribe@chromium.org.


Philip Jägenstedt

ongelezen,
31 jul. 2017 05:45:1631-07-2017
aan PhistucK, Harald Alvestrand, Guido Urdaneta, hb...@chromium.org, blink-dev
+Henrik Boström, can you take a look at this?



PhistucK

LGTM3


LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.



--
TAMURA Kent
Software Engineer, Google


--
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.


Philipp Hancke

ongelezen,
31 jul. 2017 06:32:1731-07-2017
aan PhistucK, Harald Alvestrand, Guido Urdaneta, blink-dev, Philip Jägenstedt
addTransceiver is the alternative to the legacy offerOptions, it is not going to go away as it is an integral part of the transceiver evolution of the API as described in https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

Henrik Boström

ongelezen,
14 aug. 2017 05:55:2914-08-2017
aan blink-dev, phis...@gmail.com, h...@chromium.org, gui...@chromium.org, foo...@chromium.org
addTransceiver is part of the RTP Media API, there is consensus and this is being worked on. I am currently working on the essential addTrack and removeTrack parts of this API. addTransceiver in addition will allow receiving streams earlier and should be implemented as soon as we have lower-layer support and addTrack/removeTrack is shipped.

georg...@gmail.com

ongelezen,
19 sep. 2017 00:09:2219-09-2017
aan blink-dev

emmy...@gmail.com

ongelezen,
13 nov. 2017 04:25:4113-11-2017
aan blink-dev
internership
Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten