I don't have a particularly strong opinion on the RawWebSocket vs. RawWebSocketImpl dichotomy, but it might be a bit more abstracted that necessary. I'm perfectly fine with the WebSocket vs. RawWebSocket difference, though, because one's a native browser class, while the other provides a more Java-centric interface.
Where I think there's a breakdown, though, is that the WebSocket*Handler interface, which seem to be meant to mimic the widget-level event handlers, actually pass event objects that are JSO subtypes. This is mixing up the DOM/Java levels of abstraction in a confusing way. FWIW, I think it might be worth trying to land this in two phases: 1. Native/DOM-only stuff. The rawest possible classes necessary to interface with WebSocket. 2. Java-friendly wrappers, possibly in a separate package. This distinction is much like that between XMLHttpRequest (raw native interface) and RequestBuilder (Java-friendly, & built on top of it). http://gwt-code-reviews.appspot.com/646803/diff/16001/17013 File user/src/com/google/gwt/websocket/client/RawWebSocket.java (right): http://gwt-code-reviews.appspot.com/646803/diff/16001/17013#newcode35 user/src/com/google/gwt/websocket/client/RawWebSocket.java:35: boolean useCapture); An alternative to this approach would be to use the standard EventTarget.addEventListener() signature as described in http://gwt-code-reviews.appspot.com/623803 It's a little hairier to implement, because of the need to map EventListener instances back to the lambda that wraps them, but it's easier on the user. http://gwt-code-reviews.appspot.com/646803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
