Re: Data API Proposal aligned to WebSocket

On 02/24/2012 03:00 PM, Randell Jesup wrote:
> On 2/24/2012 5:48 AM, Adam Bergkvist wrote:
>> 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?
>
> On label collision (assuming you don't have multiple channels with the
> same label):
>
> a) no glare (common case):  there's already a dataChannel object of that
> label.  Simplest would be to fail it with a specific error.You could
> also return a reference to the current object, but that could be
> confusing to the application and lead to usage errors.  Note that since
> data is delivered via a callback, it would get delivered to once, though
> the second version may overwrite the function from the first instance
> (one hopes they would be the same).
>
> b) glare: 'a' implies that we should return an error for one of them,
> but on the other hand there's no chance of the problem in 'a' (one side
> thinking there are two separate data channels).  So unless there's an
> implicit directionality to the channel in the application logic, there's
> no obvious problem.  However, we can't know if the application assumes
> directionality (i.e. the logic in some way depends on whether it was
> created as ondatachannel).  Since directionality is actually probably
> common, it's probably best to fail one of them.  So I'll reverse my
> opinion on further reflection, and suggest failing the label glare case
> on one side (side determined in some manner via the protocol).  Note
> that in very rare cases this may delay channel open and complicates the
> implementation.
>
> Note that all of this goes away (and most, though not all, failure
> handling) if we're unidirectional.  :-)
>
> As you mention, if you allow multiple channels with the same label, then
> the label glare case goes away.  You don't *have* to require in-order
> creation; you'd merely need to state that ordering of creates from side
> 1 doesn't have to match the ordering on the receive side (and that's
> only to deal with the case of creating two channels with the same label
> from the same side at virtually the same time - extreme edge case).  I
> think I prefer this solution, and it leads to a simpler wire protocol
> and implementation.  In some rare-ish cases, applications might need
> additional logic, but few would need it.

I prefer this solution as well since it removes a way for a channel 
setup to fail. This also makes the API more consistent - a successful 
channel creation on one side will always result in a "datachannel" event 
on the other side.

I think you're right that we could get away with undefined order of 
creation, but it would be very nice to have in-order if possible. In 
that case, a web app that sets up a number of channels during 
initialization could skip the labels and simply rely on order (i.e. it 
knows that the DataChannel object in the first event should go into the 
chatChannel variable and so on).

/Adam

Received on Friday, 24 February 2012 16:07:39 UTC