What are the design decisions behind Websocket API?

[dimensionscape]

I was curious about the design decisions involved in the new websocket api.
More specifically:
1.) why require manual sending of op codes?
2.) why condense server and client mechanisms into the same api?

[ajwfrost]

There's always a bit of debate about how much abstraction we provide to the underlying functionality, vs how we could make it "simple" to use. In terms of the sendMessage function, the WebSocket protocol allows you to send data in different types of message, and we didn't want to restrict this capability... if you pass in the 'TEXT' format, this is what will be sent to the server, regardless of whether you provided a String or a ByteArray object, and vice versa. And of course the 'PING' messages could also include data, etc. So, to keep it flexible/future-proof, we didn't want to constrain this or have different functions for the different message types.

For the client/server, I think that was just because so much of the underlying code would be the same. The client side was fairly clear and simple, the server was the one that caused a bit of debate; in the end we went with the idea of 'adopting' an existing socket that would have just been provided from the ServerSocket functionality. The alternative may have needed a different (or adapted) version of ServerSocket. The main thing that the startServer method does is to wait for the client HTTP request and handle the upgrade, so we had also wondered about having that capability handled separately but in the end it made more sense to keep it together particularly given how we ended up trying to provide the "protocols" functionality.

BTW, my email notification contained a bit of a different question, so if you wanted me to reply on that, please email me directly :-)

thanks