Re: DataChannels API

On 2012-09-12 06:38, Randell Jesup wrote:
> On 9/11/2012 8:30 PM, Ejzak, Richard P (Richard) wrote:
>
>> That's all that I think is needed.  There has already been
>> discussion of 2a, and it seems that the addition of the protocol
>> name and id fields (which could be optional) would be small.
>
> Adding a second protocol string (or MIME type) would be easy.  What
> to do with the string (other than make it available to the other
> side) is tougher.   The ID fields would actually have a significant
> negative impact.

We mirror the WebSocket API to a large extent with DataChannels, but we 
currently don't have the WebSocket "protocol" attribute in the spec. (I 
note that Randell has in the idl's he present in the first mail in this 
thread, but I don't see how it's set.)

In WebSockets, the protocol(s) are specified at creation time, but the 
actual protocol attribute isn't set right away. The attribute *might* be 
set when the connection is established and a sub-protocol is chosen by 
the server. If we translate this to DataChannels it would mean that 
sub-protocol selection would be added to the setup signaling and the 
B-side would have to act to select the protocol. It feels to me that 
this makes the signaling more complicated and doesn't really add 
anything that couldn't be solved in the application anyhow.

The approach where the protocol string is just transported to the other 
side is simpler indeed, but the question is how much it gives us. I can 
see two pros with it:
1. More alignment with WebSockets.
2. You could get away with simpler channel labels if you didn't have to 
put protocol info and such in the label ("chat_protocol0_...").

/Adam

Received on Wednesday, 12 September 2012 10:12:47 UTC