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

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

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 18 Jun 2012 15:53:38 +0200
Message-ID: <4FDF32E2.70409@ericsson.com>
To: public-webrtc@w3.org
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.

>
>
>>
>> /Adam
>>
>> On 2012-06-05 17:46, Justin Uberti wrote:
>>> If we do this, updateRemoteDescription needs to be able to take either
>>> an IceCandidate or a SessionDescription. These types are not
>>> interchangeable; the IceCandidate needs to have an additional field to
>>> indicate which m-line it's associated with.
>>>
>>> On Tue, Jun 5, 2012 at 11:08 AM, Eric Rescorla<ekr@rtfm.com
>>> <mailto:ekr@rtfm.com>>  wrote:
>>>
>>>      I'm pretty indifferent to these options, but is there any other
>>>      advantage to this
>>>      other than JS compactness?
>>>
>>>      -Ekr
>>>
>>>
>>>      On Tue, Jun 5, 2012 at 6:58 AM, Adam Bergkvist
>>> <adam.bergkvist@ericsson.com<mailto:adam.bergkvist@ericsson.com>>
>>>      wrote:
>>>> Hi
>>>>
>>>> This suggestion uses the SdpType attribute of SessionDescription
>>>      (discussed
>>>> in:
>>>>
>>>
>>> http://lists.w3.org/Archives/Public/public-webrtc/2012May/0047.html) to
>>>> include type information in the SessionDescription object. By
>>>      doing so, we
>>>> can have a less verbose syntax where the JavaScript developer can
>>>      work with
>>>> self-contained objects that are generated and understood by
>>>      PeerConnection.
>>>>
>>>> This doesn't reduce flexibility since the application can reset
>>>      the type of,
>>>> e.g., an "answer" to an "pranswer" to make PeerConnection
>>>      interpret it as
>>>> such.
>>>>
>>>> Example of creating an offer:
>>>>
>>>> --- Current syntax:
>>>>
>>>> pc.createOffer(function (offer) {
>>>>     pc.setLocalDescription("offer", offer);
>>>>     sendMessage(JSON.stringify({ "type": "offer", "sdp": offer }));
>>>> });
>>>>
>>>> --- Less verbose syntax:
>>>>
>>>> pc.createOffer(function (offer) {
>>>>     pc.updateLocalDescription(offer);
>>>>     sendMessage(offer);
>>>> });
>>>>
>>>> Example of handling an incoming signaling message:
>>>>
>>>> --- Current syntax:
>>>>
>>>> signalingChannel.onmessage = function (evt) {
>>>>     var msg = JSON.parse(evt.data);
>>>>     switch (msg.type) {
>>>>     case "offer":
>>>>         createPeerConnection();
>>>>         pc.setRemoteDescription(msg.type,
>>>>                                 new SessionDescription(msg.sdp));
>>>>         break;
>>>>     case "answer":
>>>>     case "pranswer":
>>>>         pc.setRemoteDescription(msg.type,
>>>>                                 new SessionDescription(msg.sdp));
>>>>         break;
>>>>     case "candidate":
>>>>         pc.addIceCandidate(new IceCandidate(msg.sdp));
>>>>         break;
>>>>     }
>>>> };
>>>>
>>>> --- Less verbose syntax:
>>>>
>>>> signalingChannel.onmessage = function (evt) {
>>>>     if (!pc)
>>>>         createPeerConnection();
>>>>
>>>>     pc.updateRemoteDescription(evt.data);
>>>> };
>>>>
>>>> /Adam
>>>>
>>>
>>>
>>
>>
>
>
Received on Monday, 18 June 2012 13:54:10 UTC

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