Re: The proposed data channel API

On Wed, Nov 9, 2011 at 10:09 AM, Stefan Håkansson LK <
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.

[...]
> };
>
> 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', 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', 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.