The IMTR Team conducts research and development on interactive music systems, gesture and sound modeling, interactive music synthesis, gesture capture systems and interfaces. The applications cover music performance and more generally all the performing arts. The use of digital techniques can be seen as augmenting or creating new performer’s instruments – transforming sound, voice, gestures, memory - creating dialogues between artists and digital media.

Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation.

the cross-browser WebSocket for realtime apps.

Yummy! RT @UNGlobalPulse Working lunch with @undp to talk #realtime data in #globaldev and brainstorm research areas.

This document defines a set of APIs to represent streaming media, including audio and video, in JavaScript, to allow media to be sent over the network to another browser or device implementing the appropriate set of real-time protocols, and media received from another browser or device to be processed and displayed locally.

I don't follow the standard language API argument as kdb+ has always had a c, java, c# api and they are very simple as they are just (de)serialization routines. Q is more intuitive to those who have studied functional/vector/set languages such as sql, lisp/scheme, haskell and matlab than more mainstream languages such as c, c# or java. Career friendly - my experience of learning Q was that it made me a better programmer; I've not heard of it hurting anyone's career.

I can speak about kdb+ functionality, performance and architecture.

Functionality - it is a virtual machine (byte code interpreter with super instructions), with built-in data types for vectors, dictionaries (hashtables) and tables. It has a bunch of built-in functions for some very powerful joins, and Q can sometimes look a bit like sql - e.g.
select size wavg price by sym from trade where date=2009.06.30, sym in `MSFT`CSCO, time within 10:00 11:00
There are feedhandlers out of the box but the c api is so simple it is quite straightforward to develop your own. And it hooks in to the common tools like excel and matlab.

Performance - Arthur Whitney has been optimizing the algorithms used in kdb+ for the last 30 years (Morgan Stanley and UBS had him for a few years to work on their trading systems). The executable is a couple of hundred kB, and is blazingly fast.

Architecture - It's a 64bit app and can be run in multithreaded, multiprocess and in a distributed mode on windows, solaris, linux and osx. It scales extremely well, although designs tend to revolve around concepts of in-memory database, on-disk database and gateways.

Last year there was a lot of talk about disk compression in the kdb+ community, but Kx chose to leave compression up to the file system software (e.g. ZFS gives a default compression ratio of about 3.3 for TAQ data) rather than implement a proprietary version themselves. Apparently another vendor had chosen to implement their own proprietary compression algorithm and was found to have slowly corrupted data, discovered some time after deployment.

There's a google group http://groups.google.com/group/personal-kdbplus and you can get a non-commercial version of kdb+ from kx.com. Kx has an internal group for commercial users.