W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

In defense of AddStream

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 15 Nov 2013 10:57:23 +0100
Message-ID: <5285F003.3000808@alvestrand.no>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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).

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...
Received on Friday, 15 November 2013 09:57:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC