Kris Zyp has published a great tutorial on using Persevere with Dojo.

The Persevere server is an open source JSON application and storage server. Persevere pairs well with Dojo; the Dojo Data paradigm has a strong correlation to Persevere’s data storage structure. Virtually everything you can create or action you can perform with Dojo Data can be persisted in Persevere’s data storage including subobjects, arrays, circular references, and functions. Combining Persevere with Dojo allows you to rapidly develop simple database applications with create, read, update, and delete (CRUD) capabilities with minimal effort.

Comet support in Persevere occurs with HTTP Channels.

You can start building applications almost instantly; no need to create schemas or table definitions ahead of time, simply start creating and building dynamic persistent objects in your data stores, and connect them to widgets for display. You can build your entire application, client and server, in JavaScript.

I was recently interviewed by InfoQ on the topics of Ajax, Comet, Bayeux, RIAs and the Dojo Toolbox.

I was asked to give my definition of Comet in reference to the enough with the connections discussion:

Comet is a collection of techniques, transports, protocols, servers, and clients to deliver low-latency data transit between the server and the client.

The XHR is the least common denominator of Comet, and everything else is an attempt to improve upon the XHR to deliver faster, real-time applications. My definition intentionally avoids some points of the debate, as I prefer to be inclusive and broad, much as Ajax has come to represent everything dynamic in a browser to most people.

I also touch briefly as Bayeux and standards bodies, and JSR-315 for Java Comet servers, and many more general development topics.

A few months ago we interviewed David Crane about his forthcoming book Comet and Reverse Ajax: The Next Generation Ajax 2.0. According to the publisher’s web site, the book will be available this week.

Also this week is OSCON where Comet Daily’s Michael Carter and Jacob Rus are speaking about Orbited including a great eight-player real-time game. Check back later this week for more details.

Also at OSCON is the talk Beautiful Concurrency with Erlang by Kevin Scaldeferri. While this talk is not limited to Comet or specifically about erlyComet, it should be a great introduction to concepts that are interesting to the Comet crowd.

After a break for June and most of July, conference season is about to pick back up again. If you’re interested in learning more about Comet, there are talks on Comet by Comet Daily contributors at the following conferences (and likely many more):

• OSCON (end July, Portland Oregon)
• Rich Web Experience (early September, Washington DC and San Jose, CA)
• Ajax Experience (late September, Boston, MA)
• Web2.0 Expo Europe (late October, Berlin, Germany)
• Javoxx (early December, Antwerp, Belgium)

In my recent review of Comet projects hosted by Google code, I ran across Rupy, which recently added a Comet chat demo, also known as the Hello World of Comet.

Rupy takes an interesting approach with a very very tiny Java server implementation. Even if Java is not your server-side language of choice, it’s worth taking a look:

Weighing less than 50KB, rupy is probably the smallest Java NIO HTTP server in the world.

Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data.

Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn’t use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency.

In the succinct words of Rupy project lead Marc Larue that help define what Comet is really all about:

As for a starting point I think that there is a bigger picture to the new-wave of web techniques that fueled rupy’s creation.

Comet and REST both have simplicity as the common energy source, after all HTTP is just TCP and web-services being over-engineered is an understatement.

Michael Carter’s recent Sockets in the Browser has received significant interest. JP Calderone wrote an example of a TCP sockets implementation for Athena in five minutes.

For anyone that hasn’t heard of Athena, it is a Twisted Python-based Comet implementation. For those familiar with LivePage (used in a number of Ajax and Comet demos including the sorely missed Jot Live) or Nevow, Athena supersedes LivePage and is worth a look.

A brief description of Nevow and Athena from the Nevow project site:

Nevow - Pronounced as the French “nouveau”, or “noo-voh”, Nevow is a web application construction kit written in Python. It is designed to allow the programmer to express as much of the view logic as desired in Python, and includes a pure Python XML expression syntax named stan to facilitate this. However it also provides rich support for designer-edited templates, using a very small XML attribute language to provide bi-directional template manipulation capability.

Nevow also includes formless, a declarative syntax for specifying the types of method parameters and exposing these methods to the web. Forms can be rendered automatically, and form posts will be validated and input coerced, rendering error pages if appropriate. Once a form post has validated successfully, the method will be called with the coerced values.

Athena - Finally, Nevow includes Athena, a two-way bridge between JavaScript in a browser and Python on the server. Athena is compatible with Mozilla, Firefox, Windows Internet Explorer 6, Opera 9 and Camino (Don’t see your favorite browser?). Event handlers can be written in pure Python and JavaScript implementation details are hidden from the programmer, with Nevow taking care of routing data to and from the server using XmlHttpRequest. Athena supports a widget authoring framework that simplifies the authoring and management of client side widgets that need to communicate with the server. Multiple widgets can be hosted on an Athena page without interfering with each other. Athena supports automatic event binding so that that a DHTML event (onclick,onkeypress,etc) is mapped to the appropriate JavaScript handler (which in turn may call the server).

David Davis, co-creator of the Cometd project, read through Michael Carter’s recent post on Sockets in the Browser points out that Sprocket.Socket also supports sockets in the browser. Sprocket is a Perl networking framework that provides a foundation for the Perl implementation of Cometd.

Additional notes from David:

One thing he didn’t consider is that you need data framing to handle raw data from sockets correctly. For instance, if you are parsing lines of data from a socket:

This is a line\r\n
This is another line\r\n
This is

You received a partial line, like the last line above. You need to wait for the rest of the line, and buffer it until you reach a line ending, which in this case is \r\n

I’m a POE programmer, and we have modules that frame data, and we call them Filters.

I have written several data framing filters in JavaScript, inspired by POE filters:
http://svn.xantus.org/sprocket/trunk/Sprocket-JavaScript/js/Ext-ux/Sprocket/
JSON, IRC, Line, etc.

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.