I'm doing some work with Nodejs and Websockets for the iTEC (http://itec.eun.org) project at the moment. The plan is to create something which will enable us to create widget-driven activities which animate lessons by giving the children controllers which can affect physical things in the environment of the classroom (integrating widgets and physical stuff is a requirement of the project).
Doing physical things is fairly straightforward - we're experimenting with a number of things including Arduino and its clones (including JeeNode - see http://jeelabs.org/). But the real challenge is the communication between widget-based controllers and the hardware.
Of course, the first question might be, "why use widgets?". I think the answer to this is that whatever we do which is really cool (or not!), there must be a simple to-hand way of reproducing what has been done. Widgets situated in an AppStore can provide a way in which teachers can easily distribute controllers to the children - no software installation, no worries about privileges, or security and anything else. Just drop them into the environment and they will work.
Well.. sort of.
But to do really interesting things, the teacher has to do something different. Their controller must have more functionality - indeed, the richer its functionality, the better. And here, widgets won't help us entirely. Teachers may have to install something - the software they want to demonstrate, the devices they want to play with. There is something to do there - but at least it's only one machine, rather that 30!
And it could be a laptop which is simply plugged into the network to do the job. Fundamentally then, the approach is one of trying to increase the range of things people can do, whilst alleviating the organisational problems, but at the same time dealing with problems of classroom management (because the teacher controls their service which they offer to the kids who access it through their controllers).
But then there have been the issues of implementation. WebSockets are still quite new, and are undergoing rapid development. That means that different versions proliferate, and usually they are incompatible. More significantly, different web browsers support different versions, or offer no support. A number of solutions have been offered, and my initial prototypes used the Java-WebSocket library by TooTallNate (see https://github.com/TooTallNate/Java-WebSocket). This worked ok in Chrome and Firefox, but struggled with other browsers. It seemed like the best option because it presented a way in which web activity (like chat) could trigger real events on a particular machine (for example, controlling a robot) - because the library was basically a Java library, and a Java application could be written to integrate with it.
And this was my problem. I wanted something that happened on the web (in a widget) to trigger something on a client machine. But the web is it's own domain, and there are good security reasons why this sort of behaviour is not allowed. However, in this case it was a requirement.
The solution I'm playing with is making me think about broader issues. It is to use NodeJS as a native client application. In other words, the thing that the teacher installs to offer their service is NodeJS. That means that I can use the more stable Socket.io libraries to handle the communication. But it also raises the issue of whether NodeJS should be just restricted to web-based applications.
The fact is that there is so much more that we can do with computers than is possible within a web browser. Even Google acknowledge this, and Chromium approaches the challenge by offering a way to bridge system libraries with web functionality. But that seems the wrong way round.
The value of the web is that it's available ready-to-hand everywhere with no need to install things. But I want to use the real-time web to create new services from my PC which can bridge into the online space where everyone can interact with them to do interesting things together.
This seems to me to be the space for the next generation (or maybe iteration) of the web. I found this diagram from http://blog.new-bamboo.co.uk/2010/1/4/brain-dump-of-real-time-web-rtw-and-websocket which I think sums up a fast emerging reality for the (re)organisation of our technology.