Re: Teasing apart the data API questions

As contributor:
On 04/15/2012 03:42 PM, Harald Alvestrand wrote:
> 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.

My personal view: no. Apart from that a lot of things in WS does not 
make sense in a p2p situation, we also create dependencies (between 
specs and WGs) that could give us problems, or at least slow down things 

AFAIK, it is pretty uncommon for W3C specs to use top level objects from 
other specs (event definitions are referenced, and of course stuff like 
the WebIDL).

> 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 Monday, 16 April 2012 07:17:28 UTC