- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 7 Jun 2011 17:36:03 +0000 (UTC)
- To: Adrian Bateman <adrianba@microsoft.com>
- cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Tue, 7 Jun 2011, Adrian Bateman wrote: > > This check-in [1] reintroduces the onerror handler that was removed > previously [2]. Since, in general, WebSocket protocol errors are fatal > and result in onclose, what is the purpose of adding this back? Ian asked me to put it back so that authors can distinguish between a server closure and a client-initiated error-driven closure. > We have removed onerror from our implementation since the previous > change and it's frustrating trying track against the spec with > unexpected updates. That's the cost of being on the bleeding edge. It's very likely that it will change again. Until we have implementation and authoring experience, we will almost certainly continue to update the specification to address new problems and use cases. If you want to implement things that don't change, then wait til someone else has implemented it and shipped it. Being on the bleeding edge means you are providing the feedback that affects the specification's development. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 June 2011 17:36:28 UTC