The Orbited blog recently provided information about improvements coming to Orbited 0.5. They’re skipping a 0.4 release, going straight from 0.3 to 0.5. There are a few notes about changes in migrating from 0.3, including:

• orbited.js still contains an Orbited.connect function, but this function now may takes only two arguments: event_cb and token. Orbited connections are now identified by a single token string. If you provide multiple arguments, the JavaScript client will simply concatenate them with commas in between.
• when you use an orbit client to send data from your web application, the list of recipients should just be strings that exactly match the token used from the JavaScript
• There is no proxy. Instead, Orbited.connect will just work in all browsers cross-port and cross-subdomain.
• You need to specify where the orbited server is via JavaScript globals. ORBITED_DOMAIN = ‘127.0.0.1′; ORBITED_PORT = 8000; for example.

While the Orbited team is offering backwards-compatibility, this is really just for convenience as they have completed changed their architecture. Gone is the simplistic message queue routing messages to the browser, replaced by a socket proxy, exposing a TCPConnection to JavaScript, relaying packets via actual, raw TCP connections on the back end.

That’s a really interesting approach that makes it much easier to integrate with arbitrary services and protocols. For full details, be sure to check out the Orbited 0.5 blog post.

If you’re looking to get started with a Comet server implementation, check out some of the following quick start guides for the Comet implementations created by contributors to Comet Daily.

• Caplin Liberator
• DWR
• ErlyComet
• GlassFish
• Jetty
• Lightstreamer (Moderato)
• Lightstreamer (Allegro, Presto, or Vivace)
• Meteor
• Orbited
• Persevere

For a quick comparison of these Comet projects, visit the Comet Maturity Guide. If you’d like us to include information about your Comet implementation, please contact us.

Bob Remeika has announced the start of a project to create a pure JavaScript Comet server.

Server-side JavaScript is a particularly hot topic recently, with Jaxer, Axiom Stack, Phobos, Rhino on Rails, and more.

A Bayeux implementation server will be released at some point that is written in pure JavaScript on top of Rhino. This is an effort to provide users with an all JavaScript stack that can be easily customized by anybody that understands JavaScript.

If you are interested in the effort (currently closed source) or are interested in obtaining a copy of the code, contact Bob at the address listed on the Cometd web site.

InfoQ is running an interview with Comet Daily’s Jean-Francois Arcand about Grizzly and bringing Comet to the masses with Atmosphere, a new POJO-based Comet framework

InfoQ: Would you like to describe to us what the Atmosphere framework is all about and what where the driving forces that led to it?

JFA: Two years ago I’ve blogged about the Grizzly Comet Framework, and since that time I was able to build a community around it. One of the drawback of the Grizzly Comet Framework is it only work with Grizzly runtime and GlassFish, which is a severe limitation. Over the year, peoples have asked to port the framework to other container like Tomcat, Jetty and Resin. So my goal with Atmosphere is to take the best from the Grizzly Comet Framework (one component who is called Grizzlet) and made it working with all container, supporting Comet or not. This way peoples don’t have to wait for the Servlet 3.0 spec before being able to write portable Comet/Ajax Push application. It also brings much more than what the Servlet 3.0 Spec will offer.

InfoQ: What about support for the Bayeux publish/subscribe protocol in both Grizzly and Atmosphere?

JFA: The Bayeux implementation can probably be implemented on top of Atmosphere. But for now, I will focus on Atmosphere itself and make sure I can grow a community around it. Once release 1.0 will be done, we will see if we can makes the Bayeux protocol working on top of it.

InfoQ: What will be the future of Grizzly with respect to Atmosphere? Is the new framework a replacement?

JFA: Atmosphere will just move the comet activities from Grizzly into a new project. Recently we have moved our grizzly-jruby extension into a new project called GlassFish scripting. Atmosphere will be our second extension to graduate to a new project.

Grizzly main component, NIO framework and its http extension will stay under the Grizzly umbrella. We are actively working on Grizzly 2.0 right now (with a new lead so I can concentrate on Atmosphere) and a lot of activities will also happens on that side.

Be sure to check out the full interview for more details.

In a follow-up to Michael Carter’s post a few months ago and a recent discussion with Greg Wilkins, I’d like to kick-off a a call for Comet case studies. If you’ve used Comet for a project, and you’d like to write a short article about your application and its implementation, or just be featured on Comet Daily, please send us a note.

The upcoming Dojo 1.2 release, scheduled for July, is a significant improvement over previous releases for Comet application developers. In Part 1 of this multi-part series on the improvements you can expect with Dojo, I’ll focus on instant messaging since chat is, after all, the hello world of Comet. Future installments will focus on improvements to the dojox.cometd client, and on the use of Dijit, Dojo’s widget system, to easily create widgets that update in real-time from live data sources.

But first, I’ll begin with an extension to Dojo that is now available. AOL recently announced the launch of the aimdojo project, an extension to Dojo that provides everything a developer needs to connect to the AIM service.

The aimdojo project provides source code for authentication, presence indication, IM widgets, sound effects common in AIM sessions, emoticon handlers, and much more. The code base makes use of dojo.io.iframe and dojo.io.script for Ajax and Comet, and takes a very event driven approach as evidenced by the following set of available event listeners and callbacks:

//"listeners" propery is an array of listeners to wim callbacks.
//You can add a listener via aim.wim.listeners.push().
//Listeners can implement the following function names:
//  onError(dataObject): An error occurred. dataObject is the error. 
//        Could be a string or an object.
//  onNeedAuth(): The user needs to go to the AIM site to authenticate.
//  ononNeedConsent(): The user needs to go to the AIM site to consent 
//        to the web site to receiving sending information on their behalf.
//  onAuthCancel(): The user canceled auth.
//  onConsentCancel(): The user did not allow access to buddy list.
//  onConsentInvalidToken(): The consent screen might send this sometimes. 
//         It seems to happen when clicking "Always Allow". Not sure what it
//         means yet.
//  onAuthConsentReceived(): The response from an auth or consent 
//         window/iframe was received.  The response may or may not be valid. 
//         Use this to close down any iframes/dialogs opened for the 
//         auth/consent flow.
//  onTokenComplete(): Indicates an OpenAuth token was successfully 
//         retrieved.
//  onUserLoad(): User's identity has been received. Should be the first 
//         successful callback after start() is called. To get the user's info, 
//         check aim.wim.user.
//  onSessionStart(): The user's session has started.
//  onSessionEnding(): The user's session is about to end. Functions that 
//         handle this event should do their job quickly.
//  onSessionEnd(): The user's session has ended.
//  onBuddyListLoad(): User's buddy list has been loaded. use aim.wim.groups
//         and aim.wim.buddies to build up the buddy list UI.
//  onIm(dataObject): An IM has been received. dataObject properties:
//         senderAimId: String. Buddy's aimId.
//         message: String. HTML instant message.
//         autoresponse: boolean. True if this is an auto response IM.
//         timestamp: integer. UTC timestamp when message was sent.
//  onPresenceChanged(dataObject): If a value in the presence info for
//         a buddy changes, this event will be sent with the following data:
//         aimId: String. Buddy's aimId.
//         oldValues: hashmap of changed presence properties. The old 
//         values are in this object. See aim.wim.buddies[data.aimId]
//         for the new/current values.   
//    onTypingChanged(dataObject): The typing status has changed 
//         for one of buddies. dataObject properties:
//         aimId: String. Buddy's aimId.
//         status: TypingStatus (see wim docs).
//    onGroupRemoved(): the requested group was deleted.
//    onGroupRenamed(): the requested group was renamed.
//    onBuddyAdded(): buddy was added
//    onBuddyRemoved(): buddy was removed

The main functionality of this library is through the inclusion of the AimPanel, which includes the other dependencies:

dojo.provide("aim.ImPanel");
dojo.require("aim._AimTemplatedWidget");
dojo.require("aim.LayoutContainer");
dojo.require("aim.StackContainer");
dojo.require("aim.browser");
dojo.require("aim.AddBuddyCard");
dojo.require("aim.BuddyList");
dojo.require("aim.ImGroup");
dojo.require("aim.ImUser");
dojo.require("aim.wim");
dojo.require("aim.widget.Pane");
dojo.require("aim.widget.AimButton");
dojo.require("aim.settings");
dojo.require("aim.widget.Dialogs");

Beyond AOL’s additions, and the already existing Dojo Cometd chat demos, comes the addition of an XMPP client thanks to a contribution by Sun Microsystems. XMPP is the protocol that makes Jabber work. The XMPP chat is not yet in Dojo’s trunk, but will soon be there, including all of the features you would expect from an XMPP client, and solid xdomain support. We’ll soon have a more extensive blog entry detailing this addition. For now, here’s some example code:

dojo.provide("dojox.xmpp.xmppSession");
 
dojo.require("dojox.xmpp.TransportSession");
dojo.require("dojox.xmpp.RosterService");
dojo.require("dojox.xmpp.PresenceService");
dojo.require("dojox.xmpp.UserService");
dojo.require("dojox.xmpp.ChatService");

dojo.provide("dojox.xmpp.PresenceService");
 
dojox.xmpp.presence = {
	UPDATE: 201,
	SUBSCRIPTION_REQUEST: 202,
//	SUBSCRIPTION_REQUEST_PENDING: 203,
	/* used when 'ask' attribute is absent on a roster item */
	SUBSCRIPTION_SUBSTATUS_NONE: 204,
 
	SUBSCRIPTION_NONE: 'none',
	SUBSCRIPTION_FROM: 'from',
	SUBSCRIPTION_TO: 'to',
	SUBSCRIPTION_BOTH: 'both',
	SUBSCRIPTION_REQUEST_PENDING: 'pending',
 
	STATUS_ONLINE: 'online',
	STATUS_AWAY: 'away',
	STATUS_CHAT: 'chat',
	STATUS_DND: 'dnd',
	STATUS_EXTENDED_AWAY: 'xa',
	STATUS_OFFLINE: 'offline',
 
	STATUS_INVISIBLE: 'invisible'
}
 
dojo.declare("dojox.xmpp.PresenceService", null, {
	constructor: function(xmppService){
		this.session= xmppService;
		this.isInvisible = false;
		this.avatarHash = null;
		this.presence = null;
		this.restrictedContactjids = {};
	},
 
	publish: function(presence){
		////console.log("Presence::publish() ", presence);
		this.presence  = presence;
		this._setPresence();
	},
 
	/**
	<presence from='juliet@capulet.com/balcony'>
	  <x xmlns='vcard-temp:x:update'>
	    <photo>sha1-hash-of-image</photo>
	  </x>
	</presence>
 
 
	<presence>
	  <x xmlns='vcard-temp:x:update'>
	    <photo/>
	  </x>
	</presence>
 
	*/
 
	_manageSubscriptions: function(contact, type){
		if (!contact){return;}
 
		if (contact.indexOf('@')==-1){
			contact += '@' + this.session.domain;
		}
 
		var req = dojox.xmpp.util.createElement("presence",
			{to:contact,type:type},true);
		this.session.dispatchPacket(req);
 
	},
 
	subscribe: function(contact){
		this._manageSubscriptions(contact, "subscribe");
	},
 
	approveSubscription: function(contact){
		this._manageSubscriptions(contact, "subscribed");
	},
 
	unsubscribe: function(contact){
		this._manageSubscriptions(contact, "unsubscribe");
	},
 
	declineSubscription: function(contact){
		this._manageSubscriptions(contact, "unsubscribed");
	},
 
	cancelSubscription: function(contact){
		this._manageSubscriptions(contact, "unsubscribed");
	}

A feature-rich and fully-functioning dojox.xmpp implementation will be part of the Dojo 1.2 release.

Bindows has recently added Comet support through BindowsFaces, a Bindows + JSF implementation, and GlassFish.

It’s great to see one of the original JavaScript toolkits adopt Comet (and Bayeux) through its GlassFish-based implementation. Bindows was originally developed by Erik Arvidsson and others back in the days before the term Ajax was coined, and prior to Erik and Emil joining Google. Bindows continues to offer a feature-rich toolkit for building great web apps.

Steffen Konerow has been working on a Comet Plugin for xajax.

xajax is a PHP Class Library for developing Ajax applications with PHP. A demo of the plugin is available. A short code snippet written in PHP generates the appropriate JavaScript delivered to the client-side:

function testComet () {
  $objResponse = new xajaxCometResponse(0.2);
  for ($i=0;$i<=5 ;++$i) {
    $objResponse->assign("progress","style.width",($i*3)."px");
    $objResponse->assign("progress","innerHTML",($i*2).'%');
    $objResponse->flush();
  }
$objResponse->alert("done");
  return $objResponse;
}

Mac Rumors continues their tradition of live-blogging major Apple events.

This is not the first time they have used simple polling to keep their site from crashing under the weight of thousands of readers following along from home, but it will certainly be the most watched WWDC ever.

Their JavaScript source is very light and targeted to just the specific needs of this page. I’m curious to know if they have experimented with long-polling, and if that would improve their performance.

The site further begs for the need of a way to educate users about real-time updates that do not require page reload:

This page uses the latest web technologies to provide live coverage of this event. The page will not visibly refresh as it has in the past — instead updates will be automatically inserted at the top of the updates section. Do not reload manually.

So, bring on the 3G, GPS, 32GB 4 MegaPixel camera iPhone with accelerometer support as a key developer feature!

Yesterday, we examined Comet projects hosted at Google Code. Today, we return with a quick summary of alternative Comet projects hosted at Sourceforge:

• Aonic Framework, a JavaScript Framework designed primarily for asynchronous push communication
• Audiomat, a kiosk-like jukebox system
• Collaborative UML Designer, a real-time collaborative web application for distributed modeling of UML 2.0 class diagrams
• Comep, a PHP Comet server
• CometBlaster, a Java implemented Comet Daemon with a message driven api
• Emerge Toolkit, a state-preserved web development framework using O/R Mapping on the back-end, and Comet-style sockets
• Ignant, a web stack that wraps your database schema with a RESTful API, generating an Ajax library, and a Comet broadcast system
• JS2J, a Java-JavaScript framework that supports mapping of objects from Java to JavaScript and vice-versa
• phpYahtzee, a PHP-implementation of Yahtzee with Ajax and Comet support
• Pushup, an HTTP streaming daemon
• SVGWT, a framework for building web applications for browsers supporting SVG combined with JavaScript, XUL, AJAX and Comet

As mentioned yesterday, these projects are of varying degree of quality and completeness. I highly recommend that some of these projects should consider merging or extending existing projects… for example, SVGWT, currently in the planning stages, should take a long look at dojox.gfx and dojox.cometd.