- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Fri, 13 Apr 2012 07:21:55 +0200
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc@w3.org
On Apr 13, 2012, at 12:31 AM, Randell Jesup wrote: > 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 Understood. I'm just trying to understand why things are as they are. I don't want to change the WebSocket API, just to understand it. Best regards Michael > 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 > randell-ietf@jesup.org > >
Received on Friday, 13 April 2012 05:22:22 UTC