Teasing apart the data API questions

After chewing on Cullen's comments for a few days, I'm starting to think 
that we can break it up into several questions. Some of these may be 
more easily answerable than others.

I'm using the term "channel" below for what's been known as a stream, a 
flow, or a data stream track - the thing that we want to map to a pair 
of SCTP channels. Please regard it as a placeholder name - the final 
name will depend on the answers to the questions, so

A: Relationship between data "channels" and WebSockets
A1: Should the data "channel" be similar enough to WebSockets that one 
could have (library) code that uses both interchangeably (with 
appropriate options set)?

I think the consensus answer here is "yes".

A2: Should that similarity be documented by having the data "channel" 
API implement the WebSockets API interface?

I don't have a consensus answer here yet.

B: Relationship between data "channels" and media stream tracks
B1: Should the data "channel" be similar to a MediaStreamTrack, 
including the ability to be part of one or more MediaStreams,, be 
connected to consumer entities, be muted, and so on?

The most common comment I've heard on this is "show me the use case 
where it makes sense". I'm not detecting consensus.

B2: If yes, should that similarity be documented by having hte dta 
"channel" API inherit from the MediaStreamTrack interface?

This only makes sense if question B1 is answered with "yes", of course.

Comments?

Received on Sunday, 15 April 2012 13:42:44 UTC