Re: Teasing apart the data API questions

On Apr 17, 2012, at 4:49 , Adam Bergkvist wrote:

> 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 property.
> 
> 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 execution.
> 
> 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.
> 
> /Adam
> 

So agree the URL is an issue that needs to be sorted out but I think it would easy to sort out a solution for this - for example return the IP/Port that the SCTP connection is going to in some URL type. Perhaps returning an empty URL would work. 

I think the goal should be to allow the object to be used by libraries that expect a WebSocket - that would allow a bunch of stuff to start that was designed for server / client usage to start being used for peer to peer usage and that seems like a good thing.

Received on Monday, 23 April 2012 17:29:38 UTC