I’ve been making various little canvas graphics for an upcoming browser-based pure-JavaScript real-time multiplayer game, and decided to implement some shape primitives. Specifically, I created functions for drawing circles and regular polygons. Then, I decided I could use some curvy and straight stars, and, based on the regular polygon code, made two more functions, regularQuadraticStar and regularStar. Here’s an example of 50 of these shapes drawn on a canvas:

First, and most simply, a circle function. This one is not too much easier than just using the «context».arc function directly, but it makes code a tiny bit clearer, and also saves a couple of lines of code for each circle:

var circle = function (context, x, y, radius) {
  var c = context;
  c.beginPath();
  c.arc(x,y,radius,0,Math.PI*2, true)
  c.closePath();
}

(more…)

The Orbited team is happy to announce the release of Orbited 0.3.0.

Orbited 0.3 is an evolutionary update to Orbited 0.2, with several new and exciting features, improved stability and efficiency, and some groundwork for future improvements.

Most notably, the Revolved publish/subscribe system has been rolled into Orbited. To start it, visit `http://orbited_server:8000/_/revolved/manage/`.

Other improvements include:

(more…)

The Orbited core development team is pleased to announce the release of Orbited 0.2.0.

Core Team:

• Michael Carter
• Jacob Rus
• Mario Balibrera

Our Goals:

• Support all major browsers without loading bars, clicks, or hour glasses
• Create a standard, interoperable Orbited js library
• Refactor transport architecture to achieve greater extensibility
• Create a plugin system
• Standardize logging / debugging output
• Standardize the urls
• Increase the separation of orbited sub modules

Orbited 0.2 is nearly a complete rewrite of most of Orbited’s internal components. It reorganizes architecture while leaving external interfaces nearly unchanged.

There are many great new features that will be documented over the course of the next few weeks via blog posts and updates to the core documentation. In particular, stay posted for information about the new plugin system. We provide a simple admin application as an example of how to create a plugin. Also stay posted for documentation on creating new transports by extending orbited’s Comet transport system.

We would like to thank the following contributors of documentation, patches, tutorials, and ideas for their time (in no particular order, and apologies to anyone we forgot to list):

• Paul Johnston
• Matthew Desmarais
• Mike Zaic
• Rob Morris
• Alex Russel
• Max Nickel
• Christian Czura
• Ciarán Walsh

After a couple days working on it, Orbited Live Help, which I mentioned last month, now seems to mostly work. There are still a few features I want to add to it, and a couple bugs to work out, but you should be able to click that link, and use Live Help to join us in the #orbited IRC channel, where the Orbited developers can answer your questions. Or if you like, just stop by to say hello.

The server-side code was left nearly untouched, from Mario’s WebIRC. But I rewrote all of the browser-side HTML, JavaScript (using jQuery), and CSS. The result is something that I think better serves its purpose as both a demonstration Orbited application (though it’s perhaps less impressive, it’s simpler to use), and as a live support chat (where extra features just get in the way). Also, it no longer has a garish color scheme: Sorry Mario, but CSS “red” should almost never be used in a design.

The JavaScript code is much cleaner, even if some functionality was removed. As one example, the code to handle the orbited event where someone leaves the chat room went from this:

function userLeft(data) {
    chat_box = document.getElementById(data[1]+'text');
    div = document.createElement('div');
    div.className = "left";
    sender = document.createElement('span');
    sender.className = "sender";
    sender.innerHTML = data[0];
    message = document.createElement('span');
    message.className = "message";
    message.innerHTML = data[1];
    linker = document.createElement('span');
    linker.innerHTML = data[2];
    div.appendChild(sender);
    div.appendChild(linker);
    div.appendChild(message);
    chat_box.appendChild(div);
    if (currentChan == data[1]) {
        box = document.getElementById('box');
        box.scrollTop = box.scrollHeight;
    };
};

To this:

function userLeft(leaver, channel, message) {
  $("<div class='informative part'></div>")
    .html("<span class='user>" + leaver + "</span> " + message + CHANNEL)
    .appendTo("#chathistory");

  removeName(leaver);
};

Needless to say, I vastly prefer the latter for clarity.

The new chat now highlights lines where someone mentions you by name, and the next version will handle tab completion of nicknames. I’d like to prettily style the user list, and maybe add some icons to it, but there’s plenty of other things to do around here in the mean time.

[Update, 2007-08-29: Add image that actually shows some people in the channel]

The original Orbited (then known as “Orbit”) logo, was tossed together by one of Michael’s friends in about 5 minutes. It has a certain charm in its complete simplicity, but I was never much of a fan, and decided that though I’m not much of a logo designer, once I joined the team, the logo had to go, and if someone else wouldn’t step up to make a new one, I’d have to do it myself.

See the original for yourself:

I doodled in Illustrator, trying to incorporate various types of “orbits” into the word “Orbited.” After a few hours, I had found a font that I liked well enough (Cronos), with a very round O that worked reasonably well as a planet or star around which to draw an orbit. After a couple of hours of fiddling, I had created a brush stroke swoosh tail with a splotch comet, orbiting the O (yes, I realize tails on comets point away from the Sun, and don’t trail behind them):

I passed this around to a few friends, who pointed out that the black text was nearly unreadable on the dark blue background. But a couple of them, including Eben, also disliked the font and the brush stroke. He was nice enough to spend some time brainstorming with me. The two of us passed back and forth a number of ideas for adding depth to the orbit line.

I liked the concept of using the line width to convey depth, as in the third of the above attempts, and the approach worked well with a clean modern font like Futura (which conveniently has a very nice round capital O), and so I finally ended up with something that looked like this:

But in passing this around to friends, a quite common response was that the new logo was too cold and impersonal. They generally preferred a re-colored (to avoid the black text) version of the brush stroke logo.

So, combining (in my opinion) the best of each, I stuck Futura into the brush stroke comet orbit, and jazzed the whole thing up with some warmer colors. The result can be seen on the main website, but here it is for good measure:

Hopefully this one is good enough.

CherryChat and the CherryChat tutorial have been on the website as long as I’ve known about Orbited, but finally they not alone, having now been joined by a RailsChat tutorial. Ruby on Rails is kind of a beast: it installs hundreds of (from my point of view) useless files and directories, and requires a developer to run a script to create a new section of a site. But I suppose it works well enough for what it’s designed for. After giving up on the discussion in the #rubyonrails channel, I asked some Ruby programmer friends how to save state, and they explained to me that adding $ before a variable name makes it global. Not long later, RailsChat was finished. The client-side code in RailsChat is pretty much copied directly from CherryChat. And the resulting apps behave pretty much identically.

It is however amusing to compare the directory structure of each version:

CherryChat:

RailsChat:

And of course the money shot (a working chat app!):

As Mario already mentioned, I find his current WebIRC interface a bit confusing. It’s non-obvious how to log in, and how to join channels, and completely unintuitive for a click on the current channel’s name to close the channel. Moreover, Orbited could use a good IRC demo, to log people into the #orbited channel, so that we can help them. So I’m working on cutting the feature set down to a minimum, slapping on some nicer-looking CSS, and putting the thing up on the main Orbited website, where non-IRC-savvy users can open it up to get Orbited help.

I shouldn’t have peeked at Mario’s JavaScript code for WebIRC. It works, but it’s confusing (what in the world is data[0][n][1]? Who named these variables anyway?), and it’s far more verbose than necessary. I’ll probably end up completely rewriting it. Fortunately the server-side shouldn’t need to be altered much if at all.

Now that we have a Ruby client API, we need a demo! So I downloaded Ruby on Rails, opened up the famous screencast, and started making my chat demo. But Python (and CherryChat) knows how to keep its state in a regular variable, whereas it wasn’t clear to me (newbie that I am) how to do that in Ruby and Rails. So I decided, as any self-respecting programmer likely would, to ask on IRC. Specifically, in the #rubyonrails channel on freenode. The discussion that resulted was a classic (long enough that I’m putting it below the fold)

(more…)

Orbited needs to have its client API ported to many languages. No one was stepping up to do this. So, despite a complete lack of Ruby experience (none of us have any Ruby experience as far as I know), I spent a few hours porting the Python simple client to Ruby. It was surprisingly straight-forward. The code undoubtedly looks like Python code, but that’s alright. It only has to work (It does what it is supposed to do from IRB anyway), it doesn’t need to look pretty; the first Ruby user who wants to use Orbited for real work will undoubtedly fix it up.

With Ruby down, only Perl, Java, PHP, and .NET are left, of our top priority languages. That means we’ve done 1/3 of our target client libraries! Feel free to pitch in a port to your favorite language; with moderate experience in the language, the port shouldn’t take more than an hour or two.

I said last time that Orbited is the future of the web (I say Orbited specifically, and not just Comet in general, because every other Comet solution I’ve looked at was deeply flawed in my opinion).

Almost every web page could make use of Comet, if for nothing else than embedding a real-time chat about the page. But the world is real-time. News sites should add stories to the main page as they come in. Financial sites should show a running ticker. Game sites should be able to make simple multiplayer games with JavaScript alone, not needing to resort to Java applets or Flash.

Unfortunately, most web developers have no chance whatsoever of building the infrastructure needed to handle Comet apps, and even building on top of existing Comet frameworks is some combination of complex and unscalable. Orbited changes the game completely. It has been carefully designed to do only one thing — handle the Comet side of a real-time web application — while leaving the rest of the application largely unchanged. So well does it hide all of the Comet-related details that a chat application can be written in less than 30 lines of code, most of it configuration code. Orbited gets out of your way.

Though I’ve committed to working on Orbited, I took a look at the other Comet solutions floating around on the web. I came back more impressed than ever with Orbited’s architecture:

• CometD — Michael covered this pretty well in his post, but I’d like to add that I tried to read through the Bayeux protocol, and looked through the CometD twisted implementation and the example code, and couldn’t find any way for my web app to send a message to a particular browser (theoretically, my web app could implement the client side of the Bayeux spec and pretend to be a browser, but this seems like excessive work for such a simple task). Also, messages seem, from my reading of the Bayeux spec, to be passed straight through from one browser to another, without any intervention by my app. Many of the interesting ideas I have for Comet applications would require processing of messages by the server, before they go back to the client.
• FdAjax — FdAjax is built in LightTPD, and based on HTTP. This has the advantage that developers already know how to deal with HTTP. Unfortunately, FdAjax suffers from all of the same problems as CometD, because it’s based on a publish/subscribe architecture. But even worse, where CometD sends JSON data structures back and forth between browsers, FdAjax allows them to send each-other arbitrary JavaScript, which then gets executed by everyone subscribed. This is a security nightmare: Users can force each-others’ browsers to lock up, crash, and delete data on the current page, or could even gather sensitive information from the page and send it to an arbitrary server.
  • [Update, 2007-09-02: I'd like to apologize for not looking closely enough at the FdAjax architecture. I apparently mistook an eval of javascript events sent from a Ruby on Rails server in this FdAjax example for an evaluation of arbitrary javascript sent from one web browser to another. It looks like none of the downsides of FdAjax listed here is accurate, so either Michael or myself will take a deeper look at the FdAjax architecture and post a more comprehensive review in the coming days.]
• Juggernaut — Juggernaut is a Comet solution for Ruby on Rails. It nearly disqualifies itself straight-up, for relying on embedded Flash to make a connection to the client. The Juggernaut developers claim that this is better because it’s not a hack (as the long-polling or iframe transports ostensibly are), but this seems pretty bogus; Flash is not designed for passing events from a server into browser-side javascript, as far as I can tell, so using it for that seems equally hackish to me. I am no fan of Ruby on Rails, and there’s no way that I can tell to use Juggernaut from my Python applications, so it’s out as far as I’m concerned. [Update, 2007-08-27: Michael expounded on these ideas in a long post.]

There are a bunch more frameworks, but I don’t have any time to discuss them here. At some point one of us will have to do a more detailed review of each of these frameworks, and others (maybe even with some diagrams!), but for now, back to Orbited.

Orbited has simple examples to examine, a very simple architecture to understand, and its documentation is improving by the day. It works on all platforms, and its client API can trivially be ported to any programming language that can handle sockets. It cuts out all the gory details, leaving web apps to worry about only their app-specific functionality. In short, it brings Comet to the regular programmer on a silver platter.

Dig in!