JsChat now has a stateless protocol. This means you can register a cookie with the server that will persist a client connection across socket sessions.
The protocol works like this:
- Connect to a server and send a JSON string with protocol set to stateless
- The server will send back a cookie
- On every subsequent request, provide the cookie
Here’s a code example: stateless_example.rb
One of the reasons for doing this is it cuts down the web app’s complexity. The old web app embedded an EventMachine module which maintained connections for each user with the server.
This actually duplicates functionality that is already in the JsChat server, and goes against the grain of the way I intended JsChat to function. The original approach made it difficult to run multiple web app processes (for example, with Passenger).
JsChat is meant to be a very simple protocol that’s easy to implement. The EventMachine session management approach was just a hack I did, reusing code from the console client.
The old web app was 440 lines of code, and it’s now 264.
I’m working on making the JsChat protocol stateless. This means that the web client’s complexity will be greatly reduced in the future.
I’m going to make the stateless mode optional, so clients can connect using sockets or single requests.
Here’s an example of a bot written with Clojure: Clojure JsChat Bot. It might not be 100% idiomatic Clojure, but it shows that talking JsChat is simple in Clojure.
Clojure comes bundled with JSON libraries for creating and parsing JSON. The parser returns a PersistentArrayMap: ((parsed-json "message") "message") accesses the message body element of a JsChat message.
I’ve made an example of a JavaScript bot for JsChat. You can run it using Rhino, and it uses Java’s sockets for connections:
$ rlwrap java -jar js.jar
Rhino 1.7 release 2 2009 03 22
js> load('bot.js')
Notice how simple the code for interpreting the protocol is. I’ve used the same strategy as the JsChat client and server code, whereby methods are executed based on the hashes returned from the server: JsChat.Responses.Display[json.display]
Kev originally wanted us to build JsChat about 3 years ago. We haven’t quite implemented his idea yet (which was about monetizing IRC-style chat), but he’s had a lot of ideas and feature suggestions for JsChat so far. One that he was particularly concerned about was emoticons, so I included them on a rainy Sunday afternoon.
I just updated the web app with a command so you can list all of them. Next time you’re in the web app, type /emotes and you’ll get a list of available emoticons.
I’ve just checked in Passenger and Rack support with a config.ru sample into the JsChat repo. It should now be easy to get JsChat working with Passenger if you use it on your servers.
I also made message submissions display in realtime in the web app’s chat transcript. This means there’s instant feedback when a message is posted.
People are repeatedly joining #jschat talking about the merits of polling. Please read this before you do that, or you’re likely to get ignored:
- Yes, I know about server-sent events and flash hacks that provide sockets
- No, we’re not going to use Juggernaut
- JsChat will gradually support native server-sent events (some browsers provide this already)
- I used polling because it works on more devices and is cleaner
- The web interface is only a small part of the system
- Stop to consider the thought that’s been put into other aspects of the web interface
JsChat is a protocol for real-time chat based on JSON. This makes it easy to build servers, clients, bots, and web-native applications.
The protocol is currently evolving: JsChat is implemented as a proof of concept as both a web and console client.
Server
The server is written with Ruby and includes unit tests.
Console Client
The console client is meant to be similar to irssi. Typing /help will show available commands. It uses Ncurses and is written with Ruby.
Web Client
The web client must be run alongside a server. The design principles are:
- Simple interface
-
Dynamic features: tab complete, URL autolinking, image URLs display inline, YouTube video URLs automatically display as embedded videos
-
Portability: only simple Ajax calls are relied on so it will run on most platforms and browsers (iPhone, etc)
Protocol Design
JsChat messages are treated like tuples: a command is provided with one or more pieces of relevant data. The command points to the payload of the message, and other items can be included to aid clients.
- Current commands are: display, change
- Messages take this format: { ‘display’ => ‘message’, ‘message’ => { ‘to’ => ‘#room’, ‘message’ => ‘This is a message’ }
- Time stamps can be included in messages to aid clients
This syntax makes it easy to create classes that interpret the protocol. Consider how simple this would be in JavaScript:
Display = { message: function(message) { ... } } Display[json['display']]
Code
Get the code from my GitHub repository.
Next
Over the next few week, I’ll post here with tutorials and tips on how to install JsChat and manage the server-side daemons. It’s running on jschat.org with Ruby 1.8, Apache and mod_proxy.
