Re: Data API Proposal aligned to WebSocket

On 02/23/2012 11:18 PM, Randell Jesup wrote:
> On 2/23/2012 3:35 PM, Michael Tuexen wrote:
>> So you want that one side creates a channel with an identifier which is a string. This is
>> transported to the other side. Right?
>> What should happen if both sides try to open a channel with the same identifier? Should
>> this result in one channel?
>> It seems that we need to messages which are exchanged...
>
> Right; this is a variation of the 'glare' case.  (Two types of glare
> here: collision on names, and collision on stream IDs selected.)  For
> "name glare", I'd just mark both sides as open and ready.  You could
> also fail one of them (requires a message back indicating failure due to
> collision) and then give an ondatachannel message saying the other side
> created it, but then you have to decide somehow how to chose which one
> "wins".  Easily doable, but gains you nothing over just telling both
> sides it's open (one place bidirectional helps you).
>

Some thoughts about collision on names (label in the API):

I think the approach with "connecting" two independently created 
DataChannels (with the same label) is a bit tricky. What would be the 
difference between calling createDataChannel("id") on both sides 1 
second apart compared to 1 minute apart? Would the objects be 
"connected" in the 1-second case but two separate endpoints in the 
1-minute case (or would it fail)? Would this be a documented feature of 
the API?

If we can decide that two calls to createDataChannel() on the A-side 
would result in two "datachannel" events on the B-side with the order 
kept, then the label argument is redundant. The order combined with the 
context of the web app would be enough to tell them apart. We could 
still have it, but then it wouldn't be a problem to allow several 
DataChannel objects to be created with the same label. I.e. the result 
would be the same - two DataChannels on each side - in both the 1-second 
case and the 1-minute case mentioned above.

/Adam

Received on Friday, 24 February 2012 10:53:45 UTC