Articles

In Orbited, we sometimes send multiple events in a single payload, particularly with the long-polling and polling transports. After we parse the data of each event, we call some event handler that a user has attached to the Orbited connection.

This time, we’ve asked our contributors the following: “With the recent addition of WebSocket to the HTML 5 recommendation, what impact will this have on your Comet implementation in both the short and long term? Do you see your approach to your preferred protocol changing as a result? What is your general impression of WebSocket?”

This is the third article in a series aimed at illustrating how to develop Lightstreamer v.3.x Adapters based on various technologies.

HTTP Channels is implemented in Dojo 1.2 with the HttpChannels module. HTTP Channels is intended to provide data synchronization and update notifications by leveraging the ubiquitous HTTP REST semantics.

At the Open Anzo project, we’re using Cometd Bayeux to expose JMS, the Java Message Service, to the browser.

A recent set of HTML5 discussions are changing the course of Comet. The HTML5 specification now offers WebSocket, a full-duplex communications channel that operates over a single socket.

I am pleased to announce, with the Orbited 0.5.x series, we provide a TCP socket for the browser.

It is an oft repeated misnomer that Comet is about long-lived HTTP connections, but this is simply not the case. Comet uses long-held HTTP requests rather than long-lived connections!

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.

It seems like everybody and their brother’s goldfish is writing a Comet server these days. The list of implementations has grown dizzyingly long, without any clear leaders emerging.