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

Re: Data API Proposal aligned to WebSocket

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 23 Feb 2012 11:13:34 +0100
Message-ID: <4F46114E.8090708@ericsson.com>
To: Randell Jesup <randell-ietf@jesup.org>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Randall Stewart <rrs@lakerest.net>, Salvatore Loreto <salvatore.loreto@ericsson.com>

Thanks for the feedback. More comments inline.

On 02/22/2012 11:50 PM, Randell Jesup wrote:
> On 2/22/2012 11:32 AM, Adam Bergkvist wrote:
>> 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.

I prefer bi-directional for the reasons you mention above - simpler API 
for two-way communication (which I think will be the most common case) 
and it basically makes this the P2P version of a WebSocket.

>> *** DataChannel ***
>> interface DataChannel {
>> readonly attribute DOMString label;
>> readonly attribute boolean reliable;
>> readonly attribute long priority;
>> // ... extend here ...
> readonly attribute boolean outoforder; // default to true for unreliable?
> readonly attribute unsigned long retryTime; // for partially reliable
> ...others perhaps

These would also have to go into the DataChannelInit dictionary 
(specified below) to be set at creation time. I think we need to 
identify what to ship in version one. Adding new settings in the future 
is quite easy since they will go into the init dictionary and therefore 
not affect the signature of the factory method. My preference would be a 
rather limited set of options that covers the use cases we have identified.

>> *** Dictionaries and Events ***
>> dictionary DataChannelInit {
>> boolean reliable;
>> long priority;
>> // ... extend here ...
>> };

Received on Thursday, 23 February 2012 10:19:07 UTC

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