W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

RE: [ACTION-43] (sdp related objects and global namespace) - way forward

From: Li Li <Li.NJ.Li@huawei.com>
Date: Fri, 15 Jun 2012 14:42:20 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B60F8F444AAC9C49A9EF0D12D05E094221697528@szxeml535-mbx.china.huawei.com>

My understanding is that we define the JS interface between the applications and the browsers. The ability for an application to manipulate what comes out of a browser, e.g. SDP, could be left to the application.
For this reason, I think we should just give SDP a type, through interfaces or dictionary. This would reduce the JS global namespace, keep the spec simple, and provides necessary flexibility for future API change.


-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, June 15, 2012 2:41 AM
To: public-webrtc@w3.org
Subject: Re: [ACTION-43] (sdp related objects and global namespace) - way forward

On 06/14/2012 05:24 PM, Dominique Hazael-Massieux wrote:
> Le jeudi 14 juin 2012 à 11:19 -0400, Justin Uberti a écrit :
>> IceCandidate and SessionDescription represent different concepts. For
>> example, IceCandidate has a label attribute to indicate which media it
>> is relevant for (it's not just a DOMString).
> That might be the intent, but not what the current spec has; if there is
> a need for two strings, I suggest a dictionary rather than a full blown
> interface.
>>   And SessionDescription will surely have methods in the future to make
>> handling SDP less messy.
> That's the part that I think was at least somewhat controversial during
> the F2F.
I was actually arguing hard *against* defining SDP manipulation methods 
in this version of the interface, but *for* keeping the SDP object so 
that we have the option of doing so in the future.

Those of us who have still not grasped the intricacies of SDP (in whose 
numbers I count myself at least half the days of the week) need to have 
some working examples of code that manipulates SDP shown to them, with 
descriptions of why the manipulations were intrinsically necessary and 
not just a bug on one or the other side, before we should dare to think 
that we know what interfaces to design.

Received on Friday, 15 June 2012 14:53:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC