- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Sat, 19 Oct 2013 01:42:05 +0200
- To: Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Takeshi Yoshino <tyoshino@google.com>, Feras Moussa <feras.moussa@hotmail.com>
What I am saying here is that there should be an unique and unified Streams API supported by all related APIs, each group where it is relevant should feel concerned instead of thinking another one might be. Le 18/10/2013 20:04, Adam Roach a écrit : > On 10/18/13 12:47, Aymeric Vitte wrote: >> >> Le 18/10/2013 19:13, Adam Roach a écrit : >>> To be clear, the .enabled flag and .stop() method are already there, >>> and they already pause/unpause the stream and tear it down, >>> respectively. I'm just proposing concrete semantics for how they >>> interact with any PeerConnection that the track is associated with. >> >> But they are not in the Streams proposal, see my other answer. >> > > To make my point clearer: this isn't the right mailing list to talk > about making changes to the API on MediaStream and MediaStreamTrack. > If I had been proposing to change those APIs, it would have been on > the public-media-capture list, not the public-webrtc list. > > All I was trying to talk about is how the existing API influences the > behavior of RTCPeerConnection, which is why I was talking about it on > this list. If you want to propose changes to MediaStream and > MediaStreamTrack, please take them to public-media-capture. > > /a -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Received on Friday, 18 October 2013 23:42:38 UTC