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

On 06/15/2012 10:32 AM, Dominique Hazael-Massieux wrote:
> Le jeudi 14 juin 2012 à 16:54 +0200, Adam Bergkvist a écrit :
>> Both SessionDescription and IceCandidate currently have constructors. We
>> could remove those and have a static factory function on PeerConnection.
>
> But before talking about factory functions (which I agree should
> probably be static functions if we want one), I think we should discuss
> the value of having constructable objects at all.
>
> I still don't see what a full fledge object brings us for IceCandidate
> over a simple dictionary (assuming we need a label — just a DOMString
> otherwise).
>
> For SessionDescription, from what I understand the argument is that we
> should have an object so that we can later add methods to modify the SDP
> content; but it seems to be that:
> * we don't know yet whether we will have any method to add;
> * it's not clear (to me at least) that the browser will need to be
> involved in these methods (vs something that an external library could
> deal with)
>
> I think the underlying question is whether we actually want to make SDP
> manipulation a first-class citizen of the platform, or just something
> that a few people will want to do and will manage on their own.
>
> As a result, it would seem to me cleaner to go with again a simple
> DOMString (or dictionary if we add type), and only make the relevant
> functions accept also a SessionDescription object later (e.g. through an
> update to the spec, or via a partial interface in the document that
> would specify the SessionDescription interface), once we know we need it
> for sure.

To me a dictionaries makes a lot of sense in an API to be used by the 
app. But having the browser deliver a "dictionary" to the app (as it 
would on e.g createOffer), what does that really mean? Could you help 
explaining a bit Dom?

>
> Dom
>
>
>

Received on Tuesday, 26 June 2012 09:11:45 UTC