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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 15 Jun 2012 08:37:47 +0200
Message-ID: <4FDAD83B.30707@alvestrand.no>
To: public-webrtc@w3.org
On 06/14/2012 05:08 PM, Adam Bergkvist 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).
That's a horrible design. One object needs to have one responsibility; 
that's what types are for.
>> 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.
That would be going backwards.
Received on Friday, 15 June 2012 06:38:22 UTC

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