W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2012

Re: Proposal for API for Data

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 12 Apr 2012 18:31:54 -0400
Message-ID: <4F8757DA.908@jesup.org>
To: public-webrtc@w3.org
On 4/12/2012 6:59 AM, Michael Tuexen wrote:
> On Apr 12, 2012, at 12:06 PM, Timothy B. Terriberry wrote:
>> Michael Tuexen wrote:
>>> Not the way send() is handled at the socket layer, but if it is common at the JS API...
>> I don't know about "common"... I'm just describing how the WebSockets API is currently defined, since we're talking about adopting and/or extending it. As I said, I would not have found this behavior obvious.
> After reading the WebSockets spec, I understand that send() doesn't return anything but can throw
> an error. For example calling send() in the state CONNECTING throws an InvalidStateError.
> Why not in all states except OPEN? That would be what I expect...

The WebSockets spec is what it is; we can either adopt-and-extend it, or 
we can make a source-largely-compatible API inspired by it, but not 
necessarily beholden to it.  Thus far we've done the latter.  The 
proposal was to do the former, and in the process we'd need to decide if 
the behaviors specified we can support, and what we'd need to do with 
currently non-matched parts of WebSockets (url, etc), and what we'd need 
to extend/modify.

The one big advantage of adopt-and-extend is that we should be able to 
pass a DataChannel object to code expecting a WebSocket and have it 
largely just work (if it's reliable/in-order).  It may also eventually 
cause us to need to track WebSockets if the API is revved.  The downside 
will largely be quirks as we've discussed.

So, should we do it?

Randell Jesup
Received on Thursday, 12 April 2012 22:36:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:27 UTC