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

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.


>
> /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 Thursday, 7 June 2012 14:30:38 UTC