- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 30 Apr 2015 17:35:14 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 30/04/15 18:10, Jan-Ivar Bruaroey wrote:
> On 4/30/15 12:52 AM, Justin Uberti wrote:
>> Obviously I prefer a deterministic outcome. But I think it would be
>> better to not include trackY in the createOffer output - it seems
>> unintuitive.
>
> I think we're forgetting that createOffer is queued. By (sometimes *)
> queueing createOffer until later, we've made a choice about the state
> createOffer should run in, and it's not the current state!
>
> As a result, copying anything from the current state seems
> counter-intuitive to me (which properties get copied and which don't?)
>
> In the following example, createOffer runs in stable state, with both
> tracks added prior:
>
> function received(offer) {
> pc.setRemoteDescription(offer);
> pc.createAnswer().then(answer => {
> pc.setLocalDescription(answer);
>
> pc.addTrack(trackX);
> pc.createOffer(); // queued until stable state!
> pc.addTrack(trackY);
> });
> }
>
>
> Excluding trackY here would be a feat, as it gets added way before
> createOffer runs (in have-remote-offer). Also, why want that?
I agree. And in this example, createOffer would be queued until
pc.setLocalDescription(answer) resolves as well, right? (And ideally I
guess the app should make sure that setLocal(answer) didn't fail before
moving on with adding tracks and making a new offer).
>
> .: Jan-Ivar :.
>
> *) "sometimes" is Zalgo. See
> https://github.com/oren/oren.github.io/blob/master/posts/zalgo.md
>
> https://github.com/w3c/webrtc-pc/pull/222 is about removing "sometimes".
>
>
Received on Thursday, 30 April 2015 17:35:41 UTC