- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Fri, 15 Jun 2012 10:32:26 +0200
- 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 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. Dom
Received on Friday, 15 June 2012 08:32:53 UTC