A couple of members of the Orbited team are in Portland for the 2008 OSCON. Michael Carter and Jacob Rus are giving a talk on Wednesday about the recent developments with sockets in the browser and how they’ll make web app development easier and faster. Michael has written two articles for Comet Daily that describe how to use the new HTML5 WebSocket spec:

• Sockets in the Browser
• Independence Day: HTML5 WebSocket Liberates Comet From Hacks

Michael and Jacob will be around after the talk to chat and answer questions.

Update: We’ve scheduled a Comet BoF for Thursday 8p-9p in room E146. Stop by to chat about anything related to Comet.

the revolution
Orbited 0.5 enables a software developer to create robust, performant network applications for the web. If you know one of the common web frameworks, or are already comfortable writing PHP, for example, just download the Orbited client for your preferred language and you’re good to go. However, if you’ve never done any web work before, or are fed up with the traditional approach, you can just bypass the HTTP hacks altogether and instead write your internet application the way folks have been writing network software since the 70s - with a socket.

(more…)

Since discussing browser sockets, I’ve been doing some research on other implementations. For some time now, David Davis has had a browser socket with his Sprocket.Socket implementation.

(more…)

There is a new tutorial for Orbited 0.5 explaining how to write an IRC client with no server-side code! This is a good introduction to using TCPSocket for implementing clients for other protocols.

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…)

We had a number of technical issues for the past few months. Adrian Weisberg has recently taken over as the administrator and editor of this blog. Now that we’re back on track you can expect blog activity to resume.

One of the most frequent problems people have with Orbited generally surfaces before they write a single line of application logic — before, in fact, they successfully start the Orbited server for the first time. This problem is pyevent. It’s a brilliant piece of software, but many of us want to build small projects or simply prototype without having to install two sets of additional headers and gcc.

To most of you, I’m sure this doesn’t sound like a great hardship. Comet developers, however, are not most of anything. We’re strange people and we often work under strange conditions. My house loses its internet connection every few minutes; other developers are subject to the irrational decrees of their admins, or the arcane limitations of their indie operating systems. People have literally decided not to use Orbited because they couldn’t compile pyevent properly. We’re modern folks, and the rule is: make it work for everyone.

(more…)

I chatted with Rob Morris this evening via the orbited livehelp demo. He later joined us with a real irc client on freenode (you don’t actually have to use the livehelp app to talk to us. Just join the irc chat.) He had a number of questions that were particularly good, so I asked him to send me all of his thoughts / concerns about orbited in an email. Within an hour he sent me an email with a list of points, all of them very valid. The list is so great that I decided to post it here. To some extent I think you can treat the coming responses as a todo list for the Orbited development team. I’ll answer some of them in my blog, but primarily I want to make the answers more accessible directly from the orbited page.

Note that I’m not suggesting that all of these are open questions — far from it. Rather, not all of these questions have answers that are accessible without reading the mailing list archives, reading this entire blog, or talking with us directly. Without further adieu, here’s his email:

So, here are my thoughts right now. This is basically a brain dump of what my concerns are after a day of looking at and playing with Orbited.

I’m sure I’m missing obvious things, and that some of my concerns aren’t valid/relevant. Take with a large grain of salt!

Documentation Gaps

Lord knows, this is a big one, but here are 4 that jump to mind.

1. You talk about lots of methods of connecting (iframe, iframe-domain, etc) but no where is there a list, with pros & cons.
2. The config file is not documented that I could see. That’s kind of a must.
3. Javascript how-tos related to Orbited would be very nice. Should be possible to build a nice JS library to do simple stuff. Until then, what is the domain of JS problems that a user would need to address to use Orbited in production?
4. Quick overview of JSON and how you’d use it with Orbited (this is not a universal tech yet, and for those that aren’t familiar, it’s ominous and scary without an introduction).

Support Issues

1. What browsers fail? (no javascript, no XSS support, IE trusted site issue… others?)
2. What net connections fail? (bad/old proxies? restrictive firewalls? HTTP 1.0 only nodes in path?)
3. Other failure cases for users?
4. What are the server requirements? (run a dedicated orbited daemon, external port, many cheapo hosting plans don’t like this)
5. How stable is the Orbited protocol? The apis? What’s the roadmap?
6. How stable is Orbited itself?
7. What kind of load can it take? Any metrics? X simultaneous connections on Y hardware?

Best Practices

Basically, I’d like to see a map of what a real production Orbited deployment would look like. At the least, you need to address the following:

1. How best to handle authentication?
2. Data scrubbing/security: <script>alert(’We have a problem’);</script>
3. What’s up with the Loading… title and hourglass cursor? How do I avoid/minimize these? Leading to…
4. Diff connection models, which is preferred? Why? What is required above and beyond the basic model?
5. Scaling overview: what would this look like for a meebo-sized website? What would be required (broad brush strokes, discussion of issues to be addressed)?
6. Failure modes: what happens when orbited dies/restarts? Is there a way to rescue the nodes? (ie track all chat messages in DB, resend state as needed, some sort of javascript reset handler for iframe?) What should I do as an orbited dev to minimize fallout from failures?

Other Issues

1. You need a wiki.
2. You need info about yourselves, including contact information. Anyone looking to use an open-source app is buying into not only the tech, but the team behind the tech for support, leadership, etc. At least an email address! I had to get yours from the google group.
3. A list of what to use this stuff for. Chat is obvious, but you can do better than “any app that needs lots of real-time communication”. Give folks a reason to get fired up. Collaborative document editing? Games? Sports scores? LiveBlogging? What are some things you envision to get folks started using the tools?
4. The Projects link in your site nav bar is broken, goes nowhere.

As I mentioned in my previous post, Jacob and I are giving presentations at the AjaxWorld conference, September 23rd-26th. The title of my topic is “Comet for Highly Scalable Applications”. Take a look at the slides — They aren’t supposed to stand for themselves; rather, they are a speaking aid. I’ll post my speaking notes to go with them at a later date.

I am responding to a rather confrontational comment post by Grzegorz Daniluk in which re responds to Jacob Rus’s post Why Orbited Doesn’t Suck. Here is the post by Grzegorz:

FdAjax allows to send directly to other users a string or a number. Moreover even this option can be disabled. It is up to a developer what he will do with that string. This is completely different from what Jacob Rus claims about FdAjax here in this post.

On Refwell blog there is example chat application which uses direct user to user communication. Mr Jacob Rus, please provide a proof that you can do what you described in you blog post. Otherwise I’ll have to treat your post simply as FUD.

Grzegorz, The authors of the Orbited blog seek only to disseminate facts. We would never intentionally misinform our readers, and I resent the accusation.

I’ve taken a closer look at Grezgor’s FdAjax blog posts, and it seems that Jacob and I have both had some misconceptions about how FdAjax works. I’ve been thinking in terms of Cometd for so long that when I saw some example code from FdAjax, I misunderstood. Specifically, I looked at this code from the blog post titled FdAjax and Mini-chat:

var opt = {
    onSuccess: function(resp) {
        try { eval(resp.responseText); } catch (e) {}
        setTimeout("fdajax.send_request();", 20);
    },
    onFailure: function(req) {
        setTimeout("fdajax.send_request();", 10000);
    },
    method: 'get',
    parameters: "cmd=wait&user_id=" + fdajax.user_id +
                "&win_id=" + fdajax.win_id + "&types=chat"
};

I noticed the eval on the third line and thought it was handling javascript events sent directly from one browser to another. This is on closer inspection not the case — Jacob’s post was written after a quick survey he took of various comet servers, and rereading it neither of us caught this — and I’m sorry for any misunderstanding that resulted. I’ll look more closely at FdAjax and put together a comprehensive review when I get a chance. In the mean time, we retract any suggestion that FdAjax is inherently insecure.

In the future, please simply point out our mistake. No need to additionally impugn our character; we have no intention of misleading readers, and are happy to make corrections when we have erred.