Re: Making RTCSessionDescription and RTCIceCandidate much more flexible

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.

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> 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]
> *Sent:* Tuesday, July 31, 2012 11:18 AM
> *To:* Li Li
> *Cc:* 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> 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]
> *Sent:* Tuesday, July 31, 2012 5:42 AM
> *To:* 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.