Quick tryouts: Websockets

By YopY on Sunday 9 January 2011 21:00
Category: -, Views: 3.155

So the other day I was in Hilversum with a few dozen developers at Xebia, running along with the programmers there in their bi-weekly off-duty experimentation slash competitions slash self-educating program (I recommend such an event to everyone out there, by the way), and I ended up in a team trying out WebSockets.

WebSockets is a new server / browser communication technology currently being drafted up by the W3C Web Applications Working Group, based on a proposal by Opera, whose goal is to provide two-way communication between a (web) server and a client, which usually is a web browser. WebSockets' main purpose is to provide a means for low-overhead communication, including a server taking the initiative to send a message to the browser.

This is contrary to AJAX, where the browser is the party taking the initiative. In a situation where a client would like to get real-time updates, such as in collaborative software (ex: Google Docs, Wave), this usually means the client would have to poll the server every few moments - even if there are no updates.

Before WebSockets was conceived, several methods were proposed and put in action to come up with a similar effect - Comet, Long polling, Flash sockets, and possibly even ETags, which greatly reduce the overhead and server-side processing for AJAX requests.

Anyways, at Xebia we went out to see how mature the technology was, and if it was ready to be put in use already. We used a library called Atmosphere, which provides both a server- and clientside library for WebSockets and similar technologies. Atmosphere is a promising project, I'd reckon, because it's more than just a WebSockets implementation (based on the unfinished WebSockets standard) - it provides graceful degradation based on browser and server support. So if you have a browser that doesn't have WebSockets implemented (or activated), the Atmosphere library automatically falls back to other available techniques - long polling, comet, the works.

Our experimentations weren't really successful, it seemed, but that's to blame on a few factors:

* WebSockets is not a proper standard yet. Any implementation is half at best. Same for HTML5 and similar technologies which, despite having become extremely popular last year, are still not finished.

* WebSockets have been disabled in all major non-IE browsers due to security issues uncovered early last December.

* Possibly, Atmosphere does not degrade gracefully at all times. The example we used didn't work when selecting websocket or automatic detection of used communication method, for example, whilst an echo test did work properly.

* We didn't actually spend a lot of time on it. The event was from 4 to 9, with dinner and a new year's reception in between, and a lot of time spent trying to get the example to work.

Anyways. I figured I'd just write an intro to a blog post on the Xebia App Incubator blog, but it turned out to be a bit longer than that. Without further ado, here's the actual official results and blog post on the matter:

Xebia App Incubator: Some quick experiments with web scokets using Atmosphere

Volgende: Very quick first impression of Mockito (compared to JMock) 01-'11 Very quick first impression of Mockito (compared to JMock)
Volgende: Java generics - Sublist method 01-'11 Java generics - Sublist method

Comments

Comments are closed