Re: Making RTCSessionDescription and RTCIceCandidate much more flexible

Just FYI,
I'll be trying this out in Chrome Canary/Chromium while waiting for the
spec to settle and should not be seen as forcing a change in.

/Tommy


On Wed, Aug 1, 2012 at 1:41 PM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tommyw@google.com
> wrote:

> 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.
>



-- 
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.