RE: Panic between createOffer() and setLocalDescription()

My concern is what you expect if you call setLocal and then createOffer again.

Matthew Kaufman

From: piranna@gmail.com [mailto:piranna@gmail.com]
Sent: Wednesday, February 19, 2014 6:09 AM
To: Matthew Kaufman (SKYPE)
Cc: Stefan Håkansson LK; Christer Holmberg; Silvia Pfeiffer; public-webrtc; Iñaki Baz Castillo
Subject: RE: Panic between createOffer() and setLocalDescription()


I don't think so, in fact I believe it fixes it: you are creating an offer description that wants to send to the other peer. Why you would need to set it again on the same object? The only valid use case I see here it's if you need to cusyomize it... I believe this way it helps to improve the principle of least surprise, specially for WebRTC new comers.

Send from my Samsung Galaxy Note II
El 19/02/2014 15:02, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net<mailto:matthew.kaufman@skype.net>> escribió:
I believe what you suggest would violate the principle of least surprise.

Matthew Kaufman

From: piranna@gmail.com<mailto:piranna@gmail.com> [mailto:piranna@gmail.com<mailto:piranna@gmail.com>]
Sent: Wednesday, February 19, 2014 1:06 AM
To: Iñaki Baz Castillo
Cc: public-webrtc; Stefan Håkansson LK; Christer Holmberg; Silvia Pfeiffer
Subject: Re: Panic between createOffer() and setLocalDescription()


> - It forces the developer to retrieve a SDP from the PeerConnection (via createOffer) and then to pass it back again to the same PeerConnection (via setLocalDescription).
>
That's the thing I find most annoying, that it's the same PeerConnection object. Wouldn't it be possible that when calling to createOffer() and createAnswer() they call internally to setLocalDescription(), so developers only need to call it explicitly if they need to modify the SDP string? This will make easier the usage of vast mayority of use cases, and also it is a backwards compatible modificatio