What is it?

RedLiteGreenLite is a small, simple app that allows a group of people to communicate the status of something. The status can be either red or green and the subject can be whatever. That may sound a bit general, but that’s the point. It can be used for whatever purpose your crazy mind can come up with. I’ll get you started:

  1. At work, we have a single shower and a lot of shweaty guys after soccer. So we know when the shower’s available, someone can turn the status red when he enters the shower and turn it green when he exits. This way nobody has to keep stopping by the shower to see if it’s available. When it’s green, it’s available. When it’s red, it’s not.
  2. At a call center, representatives are split into groups. When one group is on break, no other group is allowed to go on break. Again, when the status is red, a group is on break and other groups must continue attending the phones. When the lite is green, the next group is free to take a break.

The process is pretty simple: join a group. Other people join the same group. When others in the group change the status, you’ll be notified. When you change the status, others in the group will be notified. The status of the group will be persisted across sessions. In other words, if everyone logs out and then logs back in a week later, the status will remain as it was the last time it was set.

There’s no need to explicitly create a group. When you attempt to join a group, the group will automatically be created if it does not already exist.

The app is free. As in free free.

What technologies are used?

RedLiteGreenLite has a client portion and a server portion.

The client is the app users download and install on their computers. It’s built in Flex and published for AIR. It uses the RobotLegs MVCS framework and makes use of AMF remoting and messaging.

The server portion is built in Java using BlazeDS and is hosted on Google Apps Engine.

Ooh, that’s simply juicy. Tell me more.

Don’t mind if I do. First of all, BlazeDS is an open source implementation of AMF-based remoting and messaging. Natively it’s not compatible with Google Apps Engine, but I wanted to use GAE because it’s extremely scalable, it’s free (let’s be honest — I’m cheap like that — this is the main reason), and I wanted the challenge.

To get BlazeDS working on GAE, I recommend following Martin Zoldano’s blog post. Not only does he outline the steps you’ll need to take but he provides a critical patch to flex-messaging-core.jar as well. While you can find this patch re-distributed elsewhere, I recommend posting a comment requesting that he email you the patched jar. That’s how he seems to want to distribute his patch and I respect that. He’s really helpful and quick to respond so it shouldn’t be much trouble.

Once BlazeDS was set up and configured, I started to plan the architecture. First of all, I needed one client in the group to be able to send a message to the rest of the clients in the group. This could be achieved through the messaging service BlazeDS provides. However, messaging doesn’t store state; it just redistributes messages to clients. I needed the group’s status to be persisted to storage so (1) when a new client joins a group it can retrieve the group’s current status and (2) the group’s status can be retained even when no clients are connected.

By default, BlazeDS’s messaging configuration uses ActionScriptAdapter to receive and distribute messages between clients. It doesn’t persist messages. To do so, I extend ActionScriptAdapter and persist the status to Google Storage before sending the message out to the other clients. When clients connect to BlazeDS, they use remoting (not messaging) to retrieve the most recently persisted status for the group. After the initial status is retrieved, the client talks to other clients using the messaging service. You can see how this is set up in messaging-config.xml and in the server code.

While GAE has been really nice to get the app up and running, it does have its downsides. To send messages between clients, BlazeDS can use a few different techniques:

  • Simple polling. The client, at a standard interval, simply asks the server if there is any new information. The server responds to the request immediately regardless of whether there is new information.
  • Long polling. The client sends a request to the server. The server holds onto the request until it has something useful to tell the client at which time it sends back the response.
  • Streaming. The client opens an HTTP connection and the connection remains open. The server shoots messages down the connection whenever it has something to say. It’s an “infinate response”.

While each approach has its pros and cons, simple polling leaves a lot to be desired as it creates a lot of HTTP traffic. Unfortunately, from my testing and research, GAE doesn’t seem to support either of the other two methods. But hey, it’s free. If any of you have a java environment and would like to host RedLiteGreenLite so we can step up our game, let me know.

Last but not least, RedLiteGreenLite is open source. I’d love for you to fork the project and do something cool with it.

Fork Project

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.