Re: RECAP: Conclusion: Cloning and sharing of MediaStreamTracks - worth it?

I haven't seen any real-world use cases that shows clearly that it is a
better solution to have a MST belonging to more than one MS.
If there are roughly the same pros and cons for both sides we should stick
with the previous version; it was worked this far just fine.


On Mon, Aug 19, 2013 at 10:28 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 08/15/2013 11:42 AM, Stefan Håkansson LK wrote:
>
>> On 2013-08-13 15:57, José Luis Millán wrote:
>>
>>> Harald said:
>>>
>>>  One still open question is whether a track can be a member of multiple
>>>>  streams; there are ease-of-implementation issues that argue for saying
>>>>
>>> "no"; there are orthogonality arguments that argue "yes".(If the answer
>>> is "no", I would argue that we should have a nullable "stream" property
>>> on the track, and that AddTrack throws an exception if the "stream"
>>> property of a track that's added is not null. That makes it predictable
>>> for the API what happens if you try to add a track to a stream.)
>>>
>>> Was it finally decided whether a track can be a member of multiple
>>> streams or not?
>>>
>> I think we never did formally decide, but my take of it is:
>>
>> * The current Draft says a track can be member of multiple streams
>> * Harald proposed it should not be allowed
>> * There was not really any consensus to change, so what is in the draft
>> is still valid
>>
>> Do you see it differently Harald?
>>
>>  That was my conclusion also; my worry was not so much which decision
> we'd take, but that we made an explicit decision one way or the other, so
> that we did not have to revisit the issue.
>
>
>
>
>