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

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