Re: Making RTCSessionDescription and RTCIceCandidate much more flexible



1 aug 2012 kl. 13:43 skrev "Tommy Widenflycht (ᛏᚮᛘᛘᚤ)" <tommyw@google.com<mailto:tommyw@google.com>>:

My main objective with this proposal is to make it very simple going to/from JSON, and at the same time make it flexible if you use something else than JSON in your negotiation channel. XMPP for example.

That is a very good reason.



The json use case:

sd = new RTCSessionDescription(JSON.parse(jsonified_sd));
jsonified_sd = JSON.stringify(sd);

Some other format:

sd_type = ...;
sd_sdp = ...;
sd = new RTCSessionDescription({type:sd_type, sdp:sd_sdp});

/Tommy

On Tue, Jul 31, 2012 at 5:55 PM, Li Li <Li.NJ.Li@huawei.com<mailto:Li.NJ.Li@huawei.com>> wrote:
I’m not quite sure why an application can’t get both SDP and its type at the same time from its peer. Do you suggest that the type and SDP string for a SessionDescription may come from different JSON strings?

For example:

sd = new RTCSessionDescription({sdp:"..."});
sd.type = ...;

The application receives the SDP string in one JSON string and its type in another, and you want to construct a SD object first and set its type later on.

Thanks.
Li

From: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) [mailto:tommyw@google.com<mailto:tommyw@google.com>]
Sent: Tuesday, July 31, 2012 11:18 AM
To: Li Li
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: Re: Making RTCSessionDescription and RTCIceCandidate much more flexible

To simplify conversion to/from JSON strings.
On Tue, Jul 31, 2012 at 5:09 PM, Li Li <Li.NJ.Li@huawei.com<mailto:Li.NJ.Li@huawei.com>> wrote:
The current constructor forces the requirement that any SessionDescription object should always have two components: a type and SDP string. Your proposal relaxes this requirement to allow the object to have one or none of the components at some time.

Beside more alternative ways to construct the object, could you elaborate the use cases for this proposal?

Thanks.
Li

From: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) [mailto:tommyw@google.com<mailto:tommyw@google.com>]
Sent: Tuesday, July 31, 2012 5:42 AM
To: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: Making RTCSessionDescription and RTCIceCandidate much more flexible

Hello list members,

Today I would like to propose a small change to RTCSessionDescription and RTCIceCandidate which would make the much more flexible:

[Constructor(optional Dictionary description)]
interface RTCSessionDescription {
             attribute RTCSdpType type;
             attribute DOMString  sdp;
};

In short the single constructor takes an Dictionary which is expected to mimic its members, and the stringifier method is removed.


This has the advantages of being extremely powerful:

sd = new RTCSessionDescription();
sd.sdp = ...;
sd.type = ...;

sd = new RTCSessionDescription({sdp:"..."});
sd.type = ...;

sd = new RTCSessionDescription({type:"answer", sdp:"..."});

sd = new RTCSessionDescription(JSON.parse(some_json_string));

sd2 = new RTCSessionDescription(sd);

and in the other direction

jsonified_sd = JSON.stringify(sd);


There's some precedence in using a constructor like this in some of the base Event classes.


Regards,
Tommy

--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU law.



--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU law.



--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU law.

Received on Friday, 3 August 2012 18:03:29 UTC