Re: Data API Proposal aligned to WebSocket

On 2/24/12 6:44 PM, Adam Bergkvist wrote:
> On 02/24/2012 05:20 PM, Randell Jesup wrote:
>> On 2/24/2012 11:02 AM, Adam Bergkvist wrote:
>>> On 02/24/2012 03:00 PM, Randell Jesup wrote:
>>>> 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.
>> Yes, that's a nice side-effect.
>>
>>> 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).
>> The simplest way to do that would be to put the control messages (at
>> least create messages) on Stream 0 (and reserve it), and mark them as
>> reliable in-order.  That will guarantee order-of-creation; if we put
>> them on PPID messages in-Stream, we can't easily guarantee
>> order-of-arrival/creation.  It inherently means blocking for these
>> cases, but that's implied by the API (in-order creation).
>>
>> It may still make sense for close messages to be in-Stream (or to signal
>> close with a reset of the stream), to guarantee all messages have been
>> delivered or dropped before close.
>>
>> So: I propose we allow duplicate labels, and there will be no matching
>> of labels on creates from opposite ends, and we require in-order
>> notification of dataChannel creations via ondatachannel.
>>
>> The only remaining glare issues will be internal to the wire protocol
>> (stream number selection) and not visible to the JS API.
>>
>> At the wire level, we'd reserve stream 0 for control messages, use PPIDs
>> in the streams for typing the data blobs, and use stream reset to signal
>> dataChannel close.  Detailed protocol description will be done in IETF
>> rtcweb.
>>
>> How does this sound to people?
> Sounds good to me.
it is OK for me

/Sal

Received on Monday, 27 February 2012 13:26:59 UTC