2

In the new Jetty Versions, the WebSocket implementation was divided into several subinterfaces:

http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/websocket/WebSocket.html

Why was it a good idea to do that?
And what are good use-cases for this separation?

justGoscha
  • 24,085
  • 15
  • 50
  • 61

1 Answers1

5

Ok, now that I read more about this issue and implemented something I'll try to answer it myself.

The standard WebSocket Interface has only the methods 

onOpen(Connection con)

and 

onClose(int closeCode, String message)

with the Connection you acquire when a WebSocket is opened you can send messages to the Browser (binary, or text).

So the standard WebSocket Interface is basically just for opening a connection and sending messages to the browser.

You don't have to deal there with the other functions, e.g. when messages arrive from the Browser.

If you want additional functionality there are the other Subinterfaces of WebSocket: Websocket.OnFrame, OnBinaryMessage, OnTextMessage, OnControl

So now if you want for your WebSocket to handle text messages and binary messages you have to implement it like this:

class MyWebSocket implements  WebSocket.OnTextMessage, WebSocket.OnBinaryMessage{
    // Implementation
}

You always only need to implement the interfaces that you need for your task and not all the other functions if they are irrelevant to you. This simplifies the code and reduces code length.

justGoscha
  • 24,085
  • 15
  • 50
  • 61
  • voting this up since its a reasonable explanation and is clearer then the original question, I wasn't clear these were the interfaces you were talking about, I thought you were asking about the split of websocket client vs server interfaces. I will give you a heads up that some complex extensions are being discussed on the hybi mailing lists now that should start creeping into jetty over the next couple of months. Mux support is a prime example. – jesse mcconnell Mar 14 '12 at 13:00