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

On 2012-06-15 08:37, Harald Alvestrand wrote:
> 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's just a question of definition. The one responsibility could be to 
represent a message that needs to be sent to the other peer. Should you 
have to care if it's a candidate or an offer even if the only thing you 
want to do is to feed it to the PeerConnection object?

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

If forwards is in the direction of an API where basic usage forces 
developers to deal with ICE/SDP functionality that could have been 
abstracted - then yes.

/Adam

Received on Friday, 15 June 2012 09:45:52 UTC