Re: In defense of AddStream

Martin and Adam already said most of what I was going to say. One
additional comment...


On Fri, Nov 15, 2013 at 1:57 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> I know this may make me sound like an antediluvian, but still, someone's
> got to say it...
>
> I like the doohickeys. I really do. But I fear that by adopting,
> willy-nilly, a doohickey-centric model, rather than adding doohickeys to
> the track/stream model, we're creating a huge amount of states with subtle
> semantics that we really don't have the full perspective to sort out - and
> without a corresponding benefit.
>
> The model we've been working on so far is this:
>
> MediaStreams are designed to fit with HTML5 Media objects. Their semantics
> fit with the <audio> and <video> tags' semantics; one <video> tag needs to
> be fed one and only one MediaStream. (to my mind, that's the only argument
> in favour of MediaStreams - but it's an important one).
>

I agree this is the only argument in favor of MediaStreams. Making
MediaStreams a lightweight grouping mechanism, as proposed, allows
MediaStream to be useful for this one purpose, and not get in the way
everywhere else.


>
> When using a PeerConnection:
> - Sender side attaches a MediaStream to a PeerConnection.
> - Receiver side gets a stream, consisting of the same number, type and
> content of MediaStreamTracks.
>
> When switching to an AddTrack model, we abandon that - the JS programmer
> is free to add some tracks, all tracks or no tracks from a stream to a
> PeerConnection.
>
> Now the receiver gets some knowledge of existing streams on the sender
> side, but has no way to know if he got all the tracks for each stream, some
> tracks  for each stream, or just the knowledge that a stream exists, but
> none of the tracks (but how would the sender be able to cause that?). Or
> perhaps he knows nothing about the stream any more, and has to invent his
> own? On what criteria?
>
> This makes the model for those who use streams at all more complex to deal
> with. And what's the benefit?
>
> The model of creating a doohickey and then adding it to a PC creates even
> more complexity.
> To my mind, the doohickey represents the properties of the association
> between the track and the PeerConnection. If you create it before adding
> it, you have to answer questions like:
> - What is the doohickey's state when it's not attached to a PC?
> - What happens if a doohickey is attached to more than one PC?
> - Can you detach a doohickey from a PC? If so, what happens to it?
>
> All this complexity can be avoided by saying that in order for a doohickey
> to be created, it has to be born already knowing about its PC and its
> track, and those linkages cannot be changed, ever.
>
> My summary:
>
> - Yes, we need the doohickey.
> - Adding pc.AddTrack makes life more complicated. We shouldn't do it
> without a clear benefit, and at the moment, I don't see what the benefit is.
> - Adding doohickeys that can live independently from a PeerConnection is a
> Bad Idea, and we shouldn't do it.
>
> That's my opinions at the moment...
>
>
>
>
>