Re: Panic between createOffer() and setLocalDescription()

+1 to all you said.

Send from my Samsung Galaxy Note II
El 20/02/2014 05:28, "cowwoc" <cowwoc@bbs.darktech.org> escribió:

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