Dojo 1.6 introduces a new API for Comet-style real-time communication based on the WebSocket API. WebSocket provides a bi-directional connection to servers that is ideal for pushing messages from a server to a client in real-time. Dojo’s new dojox.socket module provides access to this API with automated fallback to HTTP-based long-polling for browsers (or servers) that do not support the new WebSocket API. This allows you start using this API with Dojo now.
Orbited, cometD-python, and other Python Comet servers have new competition in the form of Facebook’s now open source Tornado web server. Tornado was part of the technology acquired by Facebook when they purchased FriendFeed last month, and Facebook has decided to open it up under the Apache version 2 license.
Tornado supports long-polling and HTTP streaming, but also includes many of the web site building blocks found in frameworks like Django. This is a really exciting announcement as Facebook and Google (with their Wave product) have both made major announcements around Comet technologies, bringing real-time capabilities to the mainstream, under open source licenses.
REST Channels provides a mechanism for receiving notifications of data changes and integrates Comet-style asynchronous server sent messages with a RESTful data-oriented architecture. Dojo includes a REST Channels client module which integrates completely with Dojo’sJsonRestStore, allowing messages to be delivered through the Dojo Data API seamlessly to consuming widgets, with minimal effort. The REST Channels module will automatically connect to a REST Channels server, like Persevere (which offers REST Channels out of the box). However, existing infrastructure may necessitate the use of an alternate Comet server like Jetty’s cometD server. REST Channels can be used on top of another Comet protocol like Bayeux’s long-polling protocol and with a little bit of reconfiguration, you can use Dojo’s REST Channels with a cometD server to achieve Comet-REST integration.
SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.
Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.
Silicon Valley Web Builder has a series of monthly panels on topics of interest to web application developers. I had the opportunity to attend a pair of events recently, once as a speaker, once as an attendee, and the contrast between the two was intriguing. The first panel in November was focused on Comet, while the most recent panel was a comparison of Ajax toolkits.
As an attendee of the Comet panel, I found the discussion interesting, but was a bit disheartening and negative. In retrospect, the negative tone reflects the pain and disappointment Comet engineers face in trying to come up with the perfect solution for low-latency data transit across the wire. Michael Carter was the lone optimist, describing the work he has done to date with Orbited, and what the HTML5 WebSocket promises to bring us in the near future. The other panelists were not as optimistic, having been burned by specifications not adopted and the ongoing frustrations with HTTP connection limits, proxy configurations, flaky internet connections, and more—all of which prevent many of the better approaches to Comet being viable.
SitePen’sSupport service is built using a variety of interesting techniques and technologies. Read on to see how we built a system that treats the web browser as a real client tier and bridges the worlds of JavaScript, Python and PHP seamlessly to provide a great experience for our customers.
Prior to the popularity of the web, client/server applications often involved the creation of native applications which were deployed to clients. In this model, developers had a great deal of freedom in determining which parts of the entire client/server application would be in the client and which in the server. Consequently, very mature models for client/server development emerged, and often well designed optimal distribution of processing and logic could be achieved. When the web took off, the client was no longer a viable application platform, it was really more of a document viewer. Consequently the user interface logic existed almost entirely on the server. However, the web has matured substantially and has proven itself to be a reasonable application platform. We can once again start utilizing more efficient and well-structured client/server model design. There are certainly still technical issues, but we are in a position to better to build true client/server applications now.
One of the difficulties implementing Comet on Java is the lack of any acknowledgement in the current Servlet spec (v2.5) that any HTTP connection may be anything other than short-lived. Unlike many of the other components in the JavaEE stack, servlets are ubiquitous so we don't really have a choice to use an alternative.
Servlet version 3.0 is in the works, several of the people that blog at Comet Daily are on the Servlet spec expert group and want to see this oversight fixed, but it will be a while before the spec is done, and even longer before we can rely on it’s support everywhere.
In March, we introduced the SitePen Support service to provide high-quality support for Dojo, DWR and Cometd from the people who know those projects inside and out.
We’re always watching to see how we can make our services better and after listening to our early support clients we’re making changes to ensure that clients are successful with the products we support.
