The Orbited Project always strives to push the boundaries of bi-directional web technology, and then roll our advances back into standards. The Orbited.TCPSocket is a prime example — initially it was our internal standard, the separation between protocol and transport. The js.io project is targeted against the TCPSocket API instead of being built directly into Orbited because we always hoped to provide the widest range of integration. For this reason, I’m excited to announce that Lightstreamer will be joining Orbited and Sproket.Socket in supporting the js.io.TCPSocket API. This means that you will be able to swap Orbited out for Lightstreamer in any applications that depend on js.io, including applications developed against the js.io.WebSocket implementation for future-proof compliance with the HTML5 standard.

Today marked the release of Orbited 0.7.0, along with the first 0.7.0 tutorial over at CometDaily. Thanks to everyone who helped with the release.

A couple of new features include:

• Embedded Stomp broker via MorbidQ. Now you put stomp:// urls in the [listen] section of the configuration
• Reworked startup api for easier use with outside projects like WillowChat.
• Improvements to the IRC client (via js.io)
• Increased stability for Connection handling when the page is reloaded navigated away from then returned to
• Various small bug fixes
• See the commit logs and timeline

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

You may have noticed the lack of a 0.4.x release. We tried to make a number of improvements for 0.4.x, but ultimately we never thought that branch was stable enough to release. The 0.5.0 release, on the other hand, is the most stable and feature-rich version of Orbited yet. This is a pre-announcement that should give you a day or two notice and some information about porting your app to 0.5. You can expect the official release announcement over the next couple of days.

While we still support the old orbited protocol, there are a couple of differences when using Orbited 0.5.x with 0.3.x applications:

(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.

The orbited 0.4.0 branch has been under heavy development for the past month and we are finally starting to near an alpha release. While this release won’t be immediately useful to Comet developers, it can give you a good idea of what will be in the final Orbited 0.4.0 release. There’s news on a new website, the ORBIT protocol, the STOMP Protocol, layered communication, CSP, Revolved, deployability, and the goals for the 0.4 branch.

(more…)

I just received word that my talk titled “Comet for highly scalable applications” has been accepted to AjaxExperience. From the look of it, AjaxExperience will be a much nicer conference than AjaxWorld, at least in how they treat speakers. I’ve had personal assistance with scheduling from the conference organizer and they are paying my airfare. I’ll be giving a similar talk to that which I gave at AjaxWorld. As I’ve mentioned before, you can find those slides here, and the speaking outline here.

Orbited is coming along nicely. I’ve gone over all the patches that were submitted in the last month. I accepted a few directly, but most I had to rewrite. The reason is that we are skipping Orbited 0.1.6 and moving directly to Orbited 0.2.0 as most of the codebase has been changed. There’s been a complete restructuring so it’ll be easier for developers to get involved in specific parts of the project without understanding everything. In particular, creating and understanding transports will be very straightforward and will not require changing the Orbited source. We also moved away from the pipe-based urls like “/location|user,session,transport” in favor of standard query strings: “/location?user=x&session=y&transport=z”. I personally liked the look of the old urls, but the end-user never sees them, so the result was that Orbited sometimes breaks ie with no tangible benefit.

Stay tuned over the next week for Orbited 0.2.0. We’ll need help porting the documentation, though only minor changes will be needed in the javascript and application code.

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.