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

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

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Fri, 15 Jun 2012 10:32:26 +0200
Message-ID: <1339749146.3217.474.camel@altostratustier>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

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.

Received on Friday, 15 June 2012 08:32:53 UTC

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