Server-side code is based on socket.io-erlang.
The client side is an old (rather crappy) code base, orignally targeted for Node.js,
which was ported (sort of) to Google Closure.
The thing uses many tools rather heavily, so I prefer to keep js code apart from erlang code.
The code organization for a release might change significantly.
* Make sure there is an Erlang/OTP distribution in your system
* Also make sure SVN, Mercurial and Git clients are present (yes, all of them)
* pull dependencies:
$ cd server && ./rebar get-deps
$ cd deps/socketio && ./rebar get-deps # this will pull from git submodule
$ client/build.sh serve
* (re)compile the backend and start it (better do this in a separate terminal from the previous one, lots of output)
$ cd server && ./rebar compile
* open the resulting page in the browser at http://localhost:7878
A handful of details
the one used in dev mode is client/config/config.js
It emits a lot of warnings and errors but does not compile anything
* CSS is produced from LESS.js format with the less tool and is further minified
with YUI Compressor (note that YUI Compressor is never used to minify js in this environment)
* Unit testing with Google Closure is awesome, but the setup is very tricky, plovr introduced
some utilities for unit testing as of November 2011, but this has not yet been incorporated in our tool set.
* Most tasks including final compilation is done via build.sh script. We might switch to makefiles any time soon.
* If you have pulled the code from somewhere first build the server side code.
$ cd server
$ ./rebar get-deps
$ ./rebar compile
* Server can be started with
$ cd server && ./start-dev.sh
* In order for the flash-based websocket fallback to work the swf file should be served by a server, not necessarily
the socket.io one. But I use the same for both serving static files and processing socket.io requests. This is rather possible that I
try another approach soon.