W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: Updated data stream API draft

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 3 Feb 2012 08:40:10 +0100
Message-ID: <4F2B8F5A.3050709@ericsson.com>
To: public-webrtc@w3.org
On 01/27/2012 12:20 AM, Justin Uberti wrote:
> Attached as PDF.
> New in this draft: *Changes for Jan 2012 W3C meeting; tied DataStreams
> to a PeerConnection; changed DataStream base class; added MTU for
> unreliable streams; better WebSocket alignment (added other send()
> variants, removed onreadytosend); added reliable and multiparty examples.*
Some comments/suggestions - hopefully at least to some part useful:

1. I did not follow why it was an advantage that the dataStreams are 
unidirectional (this was discussed at the interim), but I note with this 
proposal bidirectional dataStreams are very natural (as a dataStream 
object is created at both ends, and the dataStream object can send and 
receive data). If we want to maintain the unidirectional property we 
would need to have different objects on the send and the receive side. 
Perhaps it is simpler to go to bidirectional?

2. I think the name dataStream is un-intuitive. I know that SCTP has a 
stream concept, but from the API perspective, you actually send discrete 
chunks of data. So I think something like dataSocket, peerSocket, 
dataPort, or something in that spirit would better reflect what the API 
does. (This is mostly cosmetics, and would mean that a common BaseStream 
class would not be used, and that local/remoteStreams could not be used 
for data - I don't have a strong opinion)

3. Perhaps rename pc.addDataStream to pc.createDataStream? (and in 
consequence of 2. above perhaps "addDataScoket").

4. You need to define the event type for "onmessage", I think the 
MessageEvent can not carry "metadata". And define formats used for seqno 
and Timestamps.

5. It should be possible to send blobs (in addition to ArrayBuffers and 

6. Seems strange to me to have states "LIVE/ENDED" on DataStream 
(dataSocket); it is as argued not really a stream, but rather a channel 
that can transport chunks of data. And presumably the dataStream 
(dataSocket) state would be tightly connected with the PeerConnection 
state - if the connection is fine data can be transported, and not 
otherwise. So to me it seems that for data the PeerConnection states are 
enough. (And if there are states LIVE/ENDED on both MediaStream and 
DataStream, should they not be in BaseStream? As should perhaps label?)

Received on Friday, 3 February 2012 07:40:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC