Re: The proposed data channel API

On 11/12/2011 07:33 AM, Justin Uberti wrote:
>
>
> On Wed, Nov 9, 2011 at 10:09 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     After looking at the two versions submitted by Justin
>
>     *
>     http://lists.w3.org/Archives/__Public/public-webrtc/2011Oct/__0119.html
>     <http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0119.html>
>     and
>     *
>     http://lists.w3.org/Archives/__Public/public-webrtc/2011Nov/__0000.html
>     <http://lists.w3.org/Archives/Public/public-webrtc/2011Nov/0000.html>)
>
>     I prefer one aspect of the older one: creating the DataStream from a
>     PeerConnection object definitely makes more sense than creating it stand
>     alone (as things like send, priority, ... has no meaning without a
>     PeerConnection). But I would like to remove the "addDataStream" method,
>     this should happen automatically as a result of doing
>     "createDataStream".
>
>     This would result in the following changes to the PeerConnection API:
>
>     interface PeerConnection {
>
>     [...]
>
>     // Creates a data stream, either reliable or unreliable.
>     // Reliability and priority cannot be changed for a stream after it
>     is created.
>     DataStream createDataStream(in DOMString label, in optional boolean
>     reliable, in optional int priority);
>     // Removes a datastream from this PeerConnection. Will trigger new
>     signaling.
>     void removeDataStream (in DataStream stream);
>
>
> While I agree that a datastream by itself is not useful at the moment,
> there may be value in future use cases (e.g. decentralized conferences)
> to allow datastreams from one peerconnection to be plugged into another
> peerconnection. So I would prefer to keep the 2-step create and add, to
> maintain symmetry with MediaStreams, as well as provide more flexibility
> in how datastreams can be plumbed in the future.

Let's see how this discussion evolves. While I think the ideas of direct 
plumbing are attractive, I fear that there is a whole lot aspects we 
need to get into the standard, such as:
* what should happen if the sendbuffer of a downstream datachannel 
builds up (if it is connected to an incoming stream)?
* what should happen if you connect one incoming stream to several 
outgoing (associated to different PeerConnections) and some of the 
downstream ones have a lower transfer rate than the incoming one?
* Should it depend on if data is unreliable or reliable?
* Should there be different options exposed to the app?
* etc

Having all data pass through the script allows the app developer to deal 
with such situations in the way preferred, without us having to think 
through and standardize all possible wanted behaviors for all possible 
situations.

As always, the best feedback will come from users of the API!


>
>     [...]
>     };
>
>     I also think that the DataStreams should be uni-directional to fit
>     better with the MediaStream's (and share an ancestor object), as
>     well as with localStreams and remoteStreams.
>
>
>     A simple example (sorry for the sloppy syntax at places):
>
>
>     1. Sender side setup
>     ====================
>     // standard setup from existing example
>     var pc = new PeerConnection('TURNS example.net
>     <http://example.net>', sendSignalingChannel);
>
>     // create a data stream; automatically appended to localStreams
>     var aLocalDataStream = pc.createDataStream("__myChannel");
>
>
>     2. Receiver side setup
>     ======================
>     // standard setup from existing example
>     var pc = new PeerConnection('TURNS example.net
>     <http://example.net>', sendSignalingChannel);
>
>     //take care of onaddstream
>     pc.onaddstream(function (evt) {
>     //the type of stream (data or media) must be identifiable
>     //if we use the same event
>     var receiveDataStream = evt;
>     }
>
>
>     Now, if the sender side does:
>
>     aLocalDataStream.send("foo");
>
>     // the message is delivered to the receiver
>
>     receiveDataStream.onmessage("__foo");
>
>
>     The sending side can discard the stream
>     pc.removeStream(__aLocalDataStream)
>
>     // new signaling is generated, resulting in onRemoveStream for the
>     receiver
>
>     pc.onremovestream(__receiveDataStream);
>
>     Would this make sense?
>
>
> I think this is a good idea. It results in better commonality with media
> streams, and it makes the handling of datastreams in multiparty
> scenarios much more tractable. You may have one transmit stream, and N
> receive streams, one for each participant in the conference.
>
> I will update my working doc with this change this week.

Great!

>

Received on Saturday, 12 November 2011 13:11:14 UTC