- From: Justin Uberti <juberti@google.com>
- Date: Thu, 7 Jun 2012 10:08:20 -0400
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-0YDn9U5=FXhYzFk3zPS3yfZn+jN41VnF1RKvoo4OFpWA@mail.gmail.com>
I do like being able to automatically unstringify, but how would the unstringify work in this case? If I were implementing updateRemoteDescription in terms of the existing API, would it be like: function updateRemoteDescription(DOMString s) { if (IsSessionDescription(s)) { SessionDescription sd = new SessionDescription(s); setRemoteDescription(sd.type, sd.description); } else if (IsCandidate(s)) { IceCandidate c = new IceCandidate(s); addIceCandidate(c); } } I also think it feels a little weird to have a function that either replaces or appends to the remote description depending on the input type, but maybe that's just a naming issue. On Thu, Jun 7, 2012 at 4:16 AM, Adam Bergkvist <adam.bergkvist@ericsson.com>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. > > /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<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<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:09:13 UTC