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>
escribió:
> I believe what you suggest would violate the principle of least surprise.
>
>
>
> Matthew Kaufman
>
>
>
> *From:* 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
>