W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Suggestion: Less verbose syntax for offer/answer handling

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 18 Jun 2012 16:47:02 -0700
Message-ID: <CABcZeBMzctHyx1+O2N0njUBG9UaEqf+P_Ww-of1e47p9js7wXw@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, public-webrtc@w3.org
On Mon, Jun 18, 2012 at 11:56 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>
> On Jun 18, 2012, at 7:53 AM, Stefan Hakansson LK wrote:
>
>> On 06/07/2012 04:29 PM, Harald Alvestrand wrote:
>>> On 06/07/2012 10:16 AM, Adam Bergkvist wrote:
>>>> Hi
>>>>
>>>> Yes, updateRemoteDescription() needs to be able to handle both. We've
>>>> talked earlier about letting the functions that feed data down to
>>>> PeerConnection take a DOMString and let the objects automatically
>>>> stringify. Then you don't have to wrap the received string in an
>>>> object unless you're actually need it.
>>> I am leery of automatic unstringifiers. They make it less clear where
>>> parse errors get reported.
>>>
>>> I also see the sense in unifying the handling for stuff that calls
>>> setRemoteDescription, but I kind of feel  that the ICE candidate update
>>> comes in another semantic category, and deserves different syntax.
>>
>> I think I agree: I like the less verbose syntax for offer/answer Adam proposed, but I think we should keep ICE candidates separate. One reason is that the app would still need to separate them out since ICE messages can be just applied, while for SDP offers/answers glare must be handled by the app.
>
> agree with you here ...  I feel pretty strongly that ICE Candidates need to be separate things from SDP Offer/Answers.

Without taking a position on the syntax in general I agree with this point.
they are totally different types of entities.

-Ekr
Received on Monday, 18 June 2012 23:48:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC