Re: Panic between createOffer() and setLocalDescription()

Harald,

If the plan is to abstract-away SDP post-1.0, then the less you allow 
users to play with it pre-1.0 the easier it will be for you to make this 
move.

Meaning: either SDP should be an unmodifiable blob (fully unspecified, 
play with it at your own risk) or you need to begin placing an 
abstraction on top of it now. What you *don't* want are users to begin 
relying on the ability to manipulate the SDP directly and cry foul when 
you attempt to remove access to it.

Either we apologize and refuse to support reasonable use-cases for 
manipulating SDP today, or we provide an API for those use-cases and not 
require users to manipulate SDP directly. SDP is not meant to be part of 
the API surface.

Gili

On 19/02/2014 7:47 PM, Harald Alvestrand wrote:
> On 02/19/2014 10:05 AM, piranna@gmail.com wrote:
>>> - 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
>> modification...
>>
> To my mind, once we have the necessary controls in place for specifying
> the properties we want out of CreateOffer, the main reason the JS would
> have for not calling SetLocalDescription is that it is not happy with
> the result of calling CreateOffer.
>
> I'm not sure that's a compelling reason to separate the two, but it's a
> possible reason, even in the absence of SDP modification.
>
> The separation also allows some timing scenarios that would otherwise be
> impossible (such as sending the SDP blob off to another entity that did
> the actual protocol negotiation, and only installing the local
> description with SetLocalDescription after negotiation was complete) -
> but we decided long ago that in this case, there was no guarantee that
> resources continued to be available, so this is a case that we might
> consider unsupported.
>
> Again, I'm not sure the reason is compelling. But then again, I don't
> see a compelling reason to change either.
>
>

Received on Thursday, 20 February 2014 04:27:24 UTC