Re: Teasing apart the data API questions

On 2012-04-17 09:39, Randell Jesup wrote:
> On 4/16/2012 3:17 AM, Stefan Hakansson LK wrote:
>> As contributor:
>> On 04/15/2012 03:42 PM, Harald Alvestrand wrote:
>>> After chewing on Cullen's comments for a few days, I'm starting to think
>>> that we can break it up into several questions. Some of these may be
>>> more easily answerable than others.
>>> I'm using the term "channel" below for what's been known as a stream, a
>>> flow, or a data stream track - the thing that we want to map to a pair
>>> of SCTP channels. Please regard it as a placeholder name - the final
>>> name will depend on the answers to the questions, so
>>> A: Relationship between data "channels" and WebSockets
>>> A1: Should the data "channel" be similar enough to WebSockets that one
>>> could have (library) code that uses both interchangeably (with
>>> appropriate options set)?
>>> I think the consensus answer here is "yes".
>> Agree.
> Agree.  And to that end we should provide (minimal) implementations of
> url, etc, even if they just throw.

I agree to A1. Then we have the question about what we need to adopt 
from the WebSocket API to fulfill A1. People (including myself) have 
argued that one reason not to implement the WebSocket interface is that 
we don't want to inherit properties such as url and extensions which we 
currently have no use for. Perhaps it would be enough to say that 
DataChannel is compatible with WebSocket on "transport level". That 
could mean what we currently have, but perhaps also include the protocol 

One alternative is to simply skip url (and friends) which will make the 
properties undefined if read. We can't throw since that would abort JS 

If some library uses, e.g., the url property it's pretty easy for a 
JavaScript developer to add it to the DataChannel object (or prototype) 
(channel.url = ""; ) before handing the instance over to the library.

I agree to pretty much everything else Randell said.


Received on Tuesday, 17 April 2012 11:49:33 UTC