Re: [hybi] Proposed way forward for WebSockets
Greg Wilkins <gregw@webtide.com> Tue, 27 July 2010 04:56 UTC
Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C78D3A6845 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 21:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqJK1KRJypq3 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 21:56:08 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5E8CB3A69AA for <hybi@ietf.org>; Mon, 26 Jul 2010 21:56:06 -0700 (PDT)
Received: by fxm1 with SMTP id 1so444793fxm.31 for <hybi@ietf.org>; Mon, 26 Jul 2010 21:56:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.106.132 with SMTP id x4mr7411367fao.15.1280206587952; Mon, 26 Jul 2010 21:56:27 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Mon, 26 Jul 2010 21:56:27 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com>
References: <ECF0E97F-1DA2-4662-BA48-F68B65AA8179@apple.com> <4C4D66AF.9030905@opera.com> <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com>
Date: Tue, 27 Jul 2010 14:56:27 +1000
Message-ID: <AANLkTi=fx=Yfm_pe9-pdCc=5sKRP=dNfDEBYCKNHFOmH@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="0016367ed6a2e9fceb048c575208"
Subject: Re: [hybi] Proposed way forward for WebSockets
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2010 04:56:10 -0000
Ian, I'm generally in agreement with the outline of your plan - specifically I think it worthwhile to get a minimalistic solution deployed sooner rather than later. But a couple of points in-line below: On 27 July 2010 10:56, Ian Hickson <ian@hixie.ch> wrote: > > There are two parts to the protocol: the handshake, and the framing. > > The handshake has basically three purposes: 1: allowing the protocol to be > served by a server that also serves HTTP on the same port; 2: protecting > existing servers and future WebSocket servers from cross-protocol attacks; > 3: allowing servers to host multiple domains and resources on the same > IP/port combination, while supporting the browser origin security model. > I would add 4: to support the deployment of future extended versions of the protocol. Thus having a mechanism for versions and feature negotiation is key in a 1.0 The framing has one purpose: provide JavaScript applications running in > Web browsers with a way to send and receive text messages to and from > WebSocket servers. > There are a number of ways that we can make the protocol also support > other goals: > > - Compression of frame data - Sending and receiving binary data > - Allowing messages to be annotated with metadata* > - Allowing multiple JavaScript applications from the same browser to > share a connection to a server (multiplexing)* I would also add (for consideration at least) - allowing connections to be annotated with metadata, If we don't, developers will just misuse the sub-protocol field for this. - chunking of large messages into multiple frames - keep alive messages - error handling and graceful shutdown (although this is already somewhat improved). All of these could be supported by future backwards-compatible changes to > the protocol, by having the client advertise support for each feature in > the handshake, and having the server opt-in to using that feature. None of > these changes require fundamental changes to the handshake. > > Two of these, marked with an asterisk above, can also be implemented by > script; therefore a good way of determining if they are truly needed is to > deploy the protocol as is, and to see if people work around the lack of > that feature by implementing it themselves. If they do, then the feature > is needed and we should add it. > I don't necessarily agree with this evaluation criteria as features like sharing connections between tabs/windows is very much more difficult to achieve in script than in browser. So I don't think lack of wide implementations in script is a good indication of desirability of these features. But I do agree that they are not necessarily required in 1.0, so long as we can see how they could be added. The other two features are clearly needed regardless, and we should add > them in the near future. (Adding features piecemeal leads to more > compliant client-side implementations, so we should not add them now.) > With regards to the support for binary data, I agree that can mostly wait until the API is in javascript to handle it. But I would also like to have one final discussion to see if we could agree to support only a single framing type that supports both binary and text - rather than enshrining multiple framing types for all time. For example, we could switch to only supporting binary data with the assumption that unless otherwise specified the binary content is UTF-8 encoded text. > Here's a proposed timeline for adding these features: > > - We fix any critical bugs (not feature additions) in the protocol as it > stands today (next 4 weeks). > > - We deploy the protocol in four or more major browser vendors (next 4 > months). > > - When binary support in WebGL is stable, we add binary support to XHR, > WebSocket, etc (a matter of months?). > > - We look at how the protocol is used (another couple of months). > > - During this time, we build client and server test suites for the > protocol. > > - We add built-in support for the features that are needed based on > implementation experience (about 6 months from now), including > compression, multiplexing, per-frame metadata annotation, etc, as > needed. > > - We update the test suites. > I think it would be a mistake to add every feature we can think of right > away, because doing so would mean that we added features before their need > was proven, and it would lead to much less conforming client > implementations. This dynamic has been proven time and time again with Web > technologies; we should not repeat that mistake. > agreed. But I do think we need to at least discuss some proposals for the extra features before a 1.0 so that we can test that we have the right extensibility to be able to add them later without breaking. It would also be advantageous to allow implementors to experiment with > ideas like multiplexing before we add the feature to the protocol, since > it would let us use their implementation experience when designing the > extensions to the protocol. Only by first getting the basic protocol out > there and then experimenting with it can we really find how these ideas > work out in real deployments. > > > (Thanks to Ian Fette for providing a sounding board for some of this.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >
- Re: [hybi] Protocol simplicity and the "amateur p… Mike Belshe
- [hybi] Protocol simplicity and the "amateur progr… Maciej Stachowiak
- Re: [hybi] Protocol simplicity and the "amateur p… Greg Wilkins
- Re: [hybi] Protocol simplicity and the "amateur p… Willy Tarreau
- Re: [hybi] Proposed way forward for WebSockets Willy Tarreau
- Re: [hybi] Protocol simplicity and the "amateur p… James Graham
- Re: [hybi] Protocol simplicity and the "amateur p… Maciej Stachowiak
- Re: [hybi] Protocol simplicity and the "amateur p… Julian Reschke
- Re: [hybi] Protocol simplicity and the "amateur p… Ian Fette (イアンフェッティ)
- Re: [hybi] Protocol simplicity and the "amateur p… James Graham
- Re: [hybi] Protocol simplicity and the "amateur p… Micheil Smith
- Re: [hybi] Protocol simplicity and the "amateur p… Greg Wilkins
- Re: [hybi] Protocol simplicity and the "amateur p… Dave Cridland
- Re: [hybi] Protocol simplicity and the "amateur p… James Graham
- Re: [hybi] Protocol simplicity and the "amateur p… Adam Barth
- Re: [hybi] Protocol simplicity and the "amateur p… James Graham
- Re: [hybi] Protocol simplicity and the "amateur p… John Tamplin
- Re: [hybi] Adding clarification regarding future … Joe Hildebrand
- Re: [hybi] Protocol simplicity and the "amateur p… Greg Wilkins
- Re: [hybi] Protocol simplicity and the "amateur p… James Graham
- [hybi] Proposed way forward for WebSockets Ian Hickson
- Re: [hybi] Proposed way forward for WebSockets Maciej Stachowiak
- Re: [hybi] Proposed way forward for WebSockets Rob Sayre
- Re: [hybi] Proposed way forward for WebSockets Greg Wilkins
- Re: [hybi] Proposed way forward for WebSockets Michael Carter
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren
- Re: [hybi] Proposed way forward for WebSockets John Tamplin
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren
- [hybi] Adding clarification regarding future revi… Ian Hickson
- Re: [hybi] Proposed way forward for WebSockets Maciej Stachowiak
- Re: [hybi] Adding clarification regarding future … Simone Bordet
- Re: [hybi] Proposed way forward for WebSockets Dave Cridland
- Re: [hybi] Adding clarification regarding future … Thomson, Martin
- Re: [hybi] Proposed way forward for WebSockets gabriel montenegro
- Re: [hybi] Proposed way forward for WebSockets Thomson, Martin
- Re: [hybi] Adding clarification regarding future … Willy Tarreau
- Re: [hybi] Proposed way forward for WebSockets gabriel montenegro
- Re: [hybi] Proposed way forward for WebSockets Willy Tarreau
- Re: [hybi] Proposed way forward for WebSockets Adam Barth
- Re: [hybi] Proposed way forward for WebSockets Willy Tarreau
- Re: [hybi] Proposed way forward for WebSockets Dave Cridland
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren
- Re: [hybi] Proposed way forward for WebSockets Lars Eggert
- Re: [hybi] Adding clarification regarding future … Pieter Hintjens
- Re: [hybi] Proposed way forward for WebSockets Greg Wilkins
- Re: [hybi] Adding clarification regarding future … Dave Cridland
- Re: [hybi] Adding clarification regarding future … Jamie Lokier
- Re: [hybi] Proposed way forward for WebSockets Jamie Lokier
- Re: [hybi] Adding clarification regarding future … Jamie Lokier
- Re: [hybi] Proposed way forward for WebSockets Jamie Lokier
- Re: [hybi] Proposed way forward for WebSockets Ian Fette (イアンフェッティ)
- Re: [hybi] Proposed way forward for WebSockets John Tamplin
- Re: [hybi] Proposed way forward for WebSockets Dave Cridland
- Re: [hybi] Proposed way forward for WebSockets Martin J. Dürst
- Re: [hybi] Proposed way forward for WebSockets Alexey Melnikov
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren
- Re: [hybi] Proposed way forward for WebSockets Martin J. Dürst
- Re: [hybi] Proposed way forward for WebSockets Greg Wilkins
- Re: [hybi] Proposed way forward for WebSockets Anne van Kesteren