Re: Teasing apart the data API questions

On Apr 15, 2012, at 3: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".
They are definitely similar (you setup a connection, you send messages, you close it).
> 
> 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.
However, there are some properties of the WebSockets, which don't really apply to channels:
1. Sending messages on a channel being in state CLOSING or CLOSE don't result in an error,
   although the messages will never make it to the peer.
2. Result codes for closing channels.
3. You don't really need a url.
4. You don't really use the extensions and protocol

I really think the version defined in
http://dev.w3.org/2011/webrtc/editor/webrtc.html
is a good start. Some points are still missing, but can be added easily.
What is missing:
* Indicate that a channel provides unordered delivery (similar to the current reliable).
* Indicate what unreliable for a channel means:
  * Limit the number of retransmissions.
  * Limit the lifetime in ms.
  So we need to specify a policy and a value.
* Some additional text for existing procedures.
> 
> 
> 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.
I don't see a use case... Actually, refining the current API defined in
http://dev.w3.org/2011/webrtc/editor/webrtc.html
should provide a very generic way of communicating. So other stuff can be build on top of it.
> 
> 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 16:57:15 UTC