Re: Data API Proposal aligned to WebSocket

Hi Michael

Find my replies inline.

On 02/23/2012 12:41 PM, Michael Tuexen wrote:
>> var chan = peerConn.createDataChannel("mylabel");
> What is the usage of 'mylabel'. It doesn't seem to be used locally or remotely.
> I assume that you want to map channels to bi-directional streams, is this right?

You're right that it's not used in either of the examples given here. 
It's a pure API-related property to help the developer identify a 
particular DataChannel object if several objects (with the same 
transport porperties) are used. E.g. you might have a DataChannel object 
with label "chat" and another with the label "game-data" for different 
purposes.

I'm not even sure if it's really needed since I think we could specify 
that two consecutive calls to createDataChannel(), which creates two 
DataChannel objects A-side, will generate two "datachannel" events on 
the B-side in the same order. If the order of the events on the B-side 
would be undefined, we would need the label property for the web app to 
know which DataChannel on the B-side that correspons to a particular 
object on the A-side. Similar to the label property on MediaStream objects.

>> *** DataChannel ***
>>
>> interface DataChannel {
>>     readonly attribute DOMString label;
> What is the semantic of this?

See above.

>>
>>     readonly attribute boolean reliable;
> This is a property of a user message, not of a stream.

That might be the case for SCTP, but it's perhaps not the best model for 
a Web API. I would really prefer to differentiate reliable and 
unreliable on DataChannel level in the API. It would make the API 
simpler to use and more aligned with existing Web APIs IMO.

>>     readonly attribute long priority;
> This is a property of a stream.

Yes, the intention is to let a DataChannel model one stream in each 
direction.

>>     // ... extend here ...
>> };
> What about unordered? When do you expect a message to be abondoned when treated unreliable?

I don't really have an opinion on when to abandon messages in unreliable 
mode.

/Adam

Received on Thursday, 23 February 2012 12:45:30 UTC