W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

Re: Update of Doohickey/AddTrack proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 13 Feb 2014 18:22:19 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
CC: Adam Bergkvist <adam.bergkvist@ericsson.com>, Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF57C19@ESESSMB209.ericsson.se>
On 2014-02-12 20:03, Martin Thomson wrote:
> On 12 February 2014 10:26, Harald Alvestrand <harald@alvestrand.no> wrote:
>> - Remove AddStream from the direct API
>> - Add two new functions:
>>    - AddStreamId (takes a stream as argument, tells the PC only that the
>> stream is
>>      interesting)
>>    - AddTrack (adds a track to the signalling)
>> - Document AddStream as an utility function that does AddStreamId +
>> AddTrack on all member tracks
>
> This was always my plan regarding this.

What happens if, at a later stage, the app does addTrack to the 
MediaStream that was earlier done AddStreamId for? Or removeTrack?

(Of course I have nothing against what is proposed in principle, I just 
fear we adding a lot of complexity for no practical gain)


> I don't see any real value in
> removing addStream().  The real gains are in moving the conceptual
> emphasis to tracks, that doesn't mean we need to jettison streams
> entirely.
>
>


Received on Thursday, 13 February 2014 18:22:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC