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

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

From: Justin Uberti <juberti@google.com>
Date: Thu, 14 Jun 2012 11:19:55 -0400
Message-ID: <CAOJ7v-00dena5HhC0x5Y-UerdZNJh1uOZqzETuvW0treOqfMYQ@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, Anant Narayanan <anant@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Jun 14, 2012 at 11:08 AM, Adam Bergkvist <
adam.bergkvist@ericsson.com> wrote:

> On 2012-06-14 14:15, Dominique Hazael-Massieux wrote:
>> Hi Adam,
>> Le jeudi 14 juin 2012 à 12:06 +0200, Adam Bergkvist a écrit :
>>> I got the task to drive action ACTION-43: Move SessionDescription and
>>> IceCandidate out of the global namespace.
>> My recommendation would be:
>> * to kill IceCandidate and replace it by a DOMString since we never use
>> it for anything else as far as I can tell;
>> * if we must keep SessionDescription (which I understand there was rough
>> consensus on, although I'm still not sure what for), we should make it a
>> [NoInterfaceObject] interface, without constructor; if we need to
>> construct the objects rather than just passing them around, we should
>> have a factory function on PeerConnection  (e.g.
>> pc.getSessionDescription) — but based on my recollection, there was
>> still doubts on what we would use these objects for
> Perhaps we could settle with just one object. It would have a type
> attribute that could be "candidate" as well as the current
> SessionDescription types. I believe a requirement on the factory method is
> to be able to take a string received from the network. Otherwise it
> wouldn't be a direct replacement for the constructor (if that's what we
> need).

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). And SessionDescription will
surely have methods in the future to make handling SDP less messy.

Combining them to save a namespace name seems like the wrong optimization.

>  That being said, I'm still secretly hoping we can find a better design
>> for the API that can encapsulate all the ICE/SDP stuff into an optional
>> part of the object that only people that want to address complex or
>> legacy-compat use cases would have to deal with…
> That would be very nice indeed.
> /Adam
Received on Thursday, 14 June 2012 15:20:53 UTC

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