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

Re: Data API Proposal aligned to WebSocket

From: caryfitz <caryfitz@employees.org>
Date: Thu, 23 Feb 2012 02:11:57 +0000
To: <public-webrtc@w3.org>
Message-ID: <1019a58f86210b3f5128de50c73dcb78@employees.org>
On Wed, 22 Feb 2012 17:50:58 -0500, Randell Jesup wrote:
> On 2/22/2012 11:32 AM, Adam Bergkvist wrote:
>> Hi
>> I got a task from the WebRTC chairs and editors to work some more 
>> with
>> the Data API, taking Justins proposal as a starting point, meet what
>> most people seem to want
>> (http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0153.html)
>> from the API and align with the Web Socket API as far as possible.
>> Comments and feedback are greatly appreciated.
> Thanks for doing this; I was going to take a whack at just this thing
> this week!  Much easier now.
>> A DataChannel object is bi-directional data channel that is 
>> decoupled
>> from the MediaStream concept. I.e., there are no local or remote
>> DataChannels since data can be written to, and read from the same
>> object. When a DataChannel is created at one end of a 
>> PeerConnection, an
>> event, with the corresponding DataChannel, is dispatched on the 
>> other
>> end. There's no need to remove a DataChannel object from it's 
>> associated
>> PeerConnection; the close() method disposes the channel similar to
>> WebSocket.
> Yeah, I'm still of two minds on the unidirectional/bidirectional
> thing.  It's certainly a simpler API if it's bidirectional (one 
> object
> type instead of two), even if many uses don't use the opposite
> direction.  It does potentially slow down channel creation, as you
> probably need a 1.5 RTT setup instead of .5 or 1.0 RTT (depending on
> if you wanted an "onopened"), and you have to handle stream-id
> 'glare'. It requires more 'networking' code to handle all this.  I
> prefer unidirectional - the mapping to streams is much simpler, but I
> realize the typical "network-style" API is at odds with what a 
> typical
> JS programmer would expect, so that's an argument for this type of
> API.
> Not a big deal, though.

WRT round trips on setup, we are stuck with whatever the underlying 
transport protocol does, in this case, SCTP.

In general, it seems easier and more natural to leave the semantics of 
SCTP alone and make the fullest use of the protocol that we can, without 
creating issues for javascript.  I don't see any issues with 

Received on Thursday, 23 February 2012 09:24:27 UTC

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