Re: Teasing apart the data API questions

On 4/16/2012 3:17 AM, Stefan Hakansson LK wrote:
> 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".
>
> Agree.

Agree.  And to that end we should provide (minimal) implementations of 
url, etc, even if they just throw.

>> 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
> significantly.

It would also mean that we'd be affected by future changes to the WS 
API, which probably is not a plus and could cause confusion or breakage.

So: No.

>> 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.
>
> Agree.

I agree there's no consensus yet, but I'll say I don't believe there are 
any great use cases, so 'no'.  MediaStreams combine strongly 
related/synchronized tracks of realtime data.  DataChannels are 
best-effort timing - you could construct a "TimeDataChannel" which is 
synchronized to media tracks, but that's not DataChannel (and I don't 
see sufficient need for it - closest would be a screen+audio sharing).

>> 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?

NA


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 17 April 2012 07:43:49 UTC