Shaun Abram
Technology and Leadership Blog
Subscribe to RSS FeedOSCON Day4: WebSockets
The first talk of the day I attended at Day 4 of OSCON was from Sean Sullivan (Aravo), who gave a talk on “Programming WebSockets“.
Intro
WebSockets is a technology that enables bidirectional communication between web browsers and server side processes. It provides a persistent connection between client & Server, hence enabling ‘push’ abilities where you can push data/notification to browsers from the client. Other client communication options to compare it with would be Ajax
and Comet (basically Ajax with long polling).
Specifications
- WebSockets API – This focuses on the client side programming model.
- WebSockets protocol – Describes the client/server communication in more detail. More complicated and 51 pages long. The WebSockets protocol is still actively being changed.
Browser Support
- Google Chrome 4.0.249.0 and higher (v5 has WebSockets enabled by default)
- Safari 5.0
- FireFox 4.0 beta 1
- IE 9: TBD
There was a suggestion that Apple have decided to disable WebSockets in iOS4 but this is unconfirmed and the speaker suspects Apple will support WebSockets in the future.
Server side support
- Apache Server – not supported yet
- Py WebSocket – designed for use with Apache Server (actually implemented by Google Chromium team.)
- There is also a DJango solution: django-websocket
- Jetty WebSocket Server – Jetty has supported WebSockets since last September. This seems to be a good option.
However, note that there is no standard service side Java API. Each Java container has it’s own API. Therefore it will likely be difficult to write WebSockets for one app server and do a straight port to another app server.
Projects
Other Java Projects supporting WebSockets:
- GlassFish/Grizzly (see a DZone posting on it here)
- jWebSocket
- JBoss Netty (see patch here)
- Caucho Resin
Sean finished by showing the Google Quake demo (also reported here).
The conclusion of the talk was on how to gracefully handle browsers that don’t support WebSockets (e.g. IE8). The main option here seems to be “The Graceful WebSocket“. This resorts back to using AJAX long pulling if WebSockets isn’t supported in the browser.
My Thoughts
WebSockets looks like one of the most interesting technologies that fall under the HTML5 umbrella. If it gets wide browser support (e.g. IE9), and perhaps some standardization on the server side, it could really take off and even potentially over take Ajax. Definitely one to watch…
Tags: ajax, comet, html, html5, oscon, websockets
I believe that WebSockets are a fantastic technology and when the spec has been sorted and there has been a much improved level of support for it that it will be the transport/communication mechanism of choice. As things stand we need either the Graceful WebSocket, or better still a layer of abstraction where the developer doesn’t need to care about the method of communication with the server.
A good comparison is document.getElementById. How many people actually use this method directly? Most developer have a favourite JavaScript library that they include by default whenever they start writing a web page that uses JavaScript. Even those that don’t use a JavaScript library will probably create a short-cut method to access the DOM in this way. Another good example the the XmlHttpRequest object.
My bet is that exactly the same thing happens with WebSockets. At the moment the support for WebSockets isn’t there so we need to fallback gracefully. If all browser vendors don’t implement WebSockets in exactly the same way we’ll need to add workarounds in the same way we’ve done for years with JavaScript event handling and more recently the XmlHttpRequest object. If the standard API isn’t exactly what everybody wants, or the calls can be condensed by using a wrapper people won’t use the API directly and will actually do so via a library layer.
So, my opinion is: don’t care about the underlying communication layer, let a library deal with that for you. Let it chose the best way of communicating with the server so you can get on with building your real-time push application.
Hello, I would like to introduce you the Bristleback Framework. It is a high level Websocket Framework written in Java and containing JavaScript client (Android client is almost ready). I consider Bristleback as a good alternative for JWebsocket. It supports Jetty/Netty/Tomcat servers. More can be found on bristleback.pl
I’m a Bristleback Framework commiter.