- 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