Hi all,
I don't mean to preempt what ever process Rajiv et al will run here,
but I thought it might be worth while to have an early reveal of any
efforts people have with websockets. That draft is in the throws of
finalisation, so any convergence of approaches that we can achieve
early would save at least somebody pain later.
So I'll give some pointers here to the current jetty approach and
would welcome if anybody else could contribute pointers to their own
approach.
Jetty supports Upgrade in the container now by allowing a servlet to
process upgrade requests, to accept or deny them. If they wish to
accept them, they send a 101 response, but also attach a new
Connection instance that will take over the handling of the TCP/IP
connection after the upgrade. In this case it will be a
WebSocketConnection supporting one of the many dialects out there at
the moment. Such connection objects are by their nature very
container specific and I think the main challenge we have for a
generic upgrade/websocket API is to abstract that away and to hide the
container specifics and to allow the containers to provide their own
protocol handlers, while not preventing applications from also
providing their own protocol handlers.
The websocket connection instance passed back to the container has a
reference to a websocket instance created by the application. The
API I currently have is here:
http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/websocket/WebSocket.html
This is a bit of a schizo interface (with it's multiple sub interface)
as it is trying to be either a simple application interface or a
powerful websocket extension interface, all the time having to avoid
constants like opcodes (which have changed and may do so again).
I make no representations that this is the best way to proceed, or
even a good way... it is just how we have done it so far. Users have
been warned that significant changes to this API are likely.
cheers