Add HTML5 WebSocket support

[dankurka]

Originally reported on Google Code with ID 4960

http://dev.w3.org/html5/websockets/

Reported by jieryn on 2010-05-21 17:27:58

[dankurka]

Already requested:

http://code.google.com/p/google-web-toolkit/issues/detail?id=4326

Reported by jimdouglas.basis on 2010-05-21 17:31:45

[dankurka]

That seems to be requesting java.net.Socket support be mapped into WebSocket somehow.
I 
don't think that is desirable or feasible or even useful. It would be much nicer if
GWT 
would:

 (1) automatically detect if incoming client can utilize websockets
 (2) if websockets support is available on the client
 (3)   && the GWT application has not specifically disabled websockets (in .gwt.xml)
 (4) then promote all GWT-RPC requests through a dedicated websocket connection

I suspect that the default behavior I've outlined here would cover the majority of
use cases 
that most GWT applications desire. Also, I think this is quite different from issue
4326. 
Thanks!! :-)

Reported by jieryn on 2010-05-21 17:44:59

[dankurka]

I'm making some test on GWT and websockets, 

I've basically ported the implementation of WebSockets available in Google Wave Protocol
(https://code.google.com/p/wave-protocol/source/browse/src/com/google/gwt/websockets/)

into this project published on Github:
https://github.com/cristcost/gwt-websocket

It works on latest Chrome and Firefox on both Mac and Windows. It works on IE11 but
don't work on Safari on the Mac.

Reported by cristiano.costantini on 2014-02-03 17:24:46

[dankurka]

I agree this is a good first start, but it isn't really a GWT version of WebSocket.
GWT makes writing client code easy, that's one of its core features. So in the example
project you have a scripts/ws.js -- I think this is the code that needs to be inside
GWT itself. So some sort of compiler which will produce the correct Javascript, where
we can work with native GWT objects directly. In your example, we should be able to
code the callback in Java and pass in the FlowPanel to append new messages to..

Reported by jieryn on 2014-02-03 18:28:12

[dankurka]

nope ;-)
"scripts/ws.js" is only used by the page simple.jsp that implements the client in regular
Javascript (with a little of jQuery), while the GWT example is demonstrated in page
gwt.jsp.

And the code is also inside GWT itself: have a look at https://github.com/cristcost/gwt-websocket/blob/master/src/main/java/com/google/gwt/websockets/client/WebSocket.java
(which I repeat comes from https://code.google.com/p/wave-protocol/source/browse/src/com/google/gwt/websockets/)

The GWT code does exactly as you say: "code the callback in Java and pass in the FlowPanel
to append new messages":
1. The callback class is the "WebSocketApp", in fact it implements WebSocketCallback
-> https://code.google.com/p/wave-protocol/source/browse/src/com/google/gwt/websockets/
2. The handling of the callback append the message to the FlowPanel -> https://github.com/cristcost/gwt-websocket/blob/master/src/main/java/net/cristcost/study/gwtws/client/WebSocketApp.java#L75

regards and thank you very much for the feedback ;-)

Reported by cristiano.costantini on 2014-02-03 18:52:39

[dankurka]

Ok, I see that now. Thank you, sorry for the confusion. :)

How do you envision making a seamless GWT-RPC bridge over Websocket?

Also, how about using JSR 356 instead of implementation specific?

Reported by jieryn on 2014-02-04 18:14:48

[dankurka]

I think that the serialization API should be extracted from GWT-RPC (maybe it is already
in this way) so that it could be possible to de/serialize to string, on the server
and on the browser, 

Then a new API specific for this should be made that make it easy to choose a proper
type for messages from server and client.
I think to a generic class like  GWTSocket<T,P>() that have the server that sends messages
of type T and client that sends messages of type P.
The compiler should detect T and P and process for serialization in the same way it
does for classes used by RPC service.

Reported by cristiano.costantini on 2014-02-04 23:06:54

[dankurka]

About JSR 356, 
I had a look at it and I preferred the Jetty Way even if it is not standard: Jetty
uses an HttpServlet and it seems to me it better lives with Web environments,

anyhow if serialization is extracted both server side approaches could be adapted easily
- in the end both endpoint sends and receive message.

Reported by cristiano.costantini on 2014-02-04 23:15:01

[dankurka]

GWT-RPC: I like what you're saying, I think that we could actually leverage JSR 356
message Encoder and Decoder. It'd just be writing a GWT-RPC-like marshaller/unmarshaller.

JSR 356: More on this: I appreciate that you've got experience with a particular implementation
that seems correct, but it will be a real mistake to not code to JSR 356 specification
standard. Even Jetty is implementing this specification, so it is clear to me that
binding ourselves to a container-specific pre-JSR implementation is not a good idea
for the long term..

Reported by jieryn on 2014-02-05 02:26:39

[dankurka]

GWT-RPC cannot be made to work seamlessly over a WebSocket, because your async method
could be declared with a Request or even RequestBuilder return type, tying it tightly
to HTTP and RequestBuilder.
As Cristiano said, it's certainly possible to build an RPC API (using the same serialization
as GWT-RPC or not) that could work seamlessly over either HTTP or WebSocket. Actually,
that API exists already: RequestFactory can quite easily be made to work over WebSockets
thanks to its abstraction of RequestTransport on the client side and SimpleRequestProcessor
on the server side.

But maybe that discussion should be moved to the forum?

Re. WebSockets, has anyone of you looked at Elemental? (elemental.html.WebSocket)

Reported by t.broyer on 2014-02-06 10:10:56