Re: Missing Features: Stream Control

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:35 UTC