- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 15 Jun 2012 08:37:47 +0200
- 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