subbu.org

Last week, Opera posted a blog entry describing a different style of doing server push. The technique described is based on server side DOM events as currently proposed in the WHATWG Web Applications 1.0 specification. Also check out the demo, which is based on an early and partial implementation of server side events in Opera 9.x. The approach described can be used to send events over long-running connections to the browser, and in someways resembles the onload event handler of the XMLHttpRequest as implemented in Firefox. But there are some key differences between these approaches.

XMLHttpRequest’s onload (Firefox)

As I described in Dissecting Ajax Server Push, Firefox’s approach is based on an onload event handler registered for XMLHttpRequest.

On the client side, you would create an XMLHttpRequest, and register an onload event handler.

XMLHttpRequest request = new XMLHttpRequest();
request.multipart = true;
request.onload = function(e)
{
// ...
};
request.open('GET', url, true);
request.send(null);

In response to this request, the server is required to send back response of content-type multipart/x-mixed-replace, and send data in multiple parts. Whenever a part is received, the browser would call the onload function with the part received.

However the downside of this approach is that keeping the connection open from the browser-end. You need to come up with some non-trivial steps to detect dropped connections, and reopen the XMLHttpRequest to continue to receive data from the server side.

Server-side DOM Events (Opera 9.x, and Web Applications 1.0 draft)

Server side DOM events can be used to solve the same use case differently. Instead of creating an XMLHttpRequest, you would simply add an event-source element in your HTML,

and then associate event handlers with it.

document.getElementById("eventSourceId")..addEventListener("someEventNamt", myFunc, false);
function myFunc(event)
{
alert(event.data);
}

The event-source element is automatically processed by the browser. It would open a connection to the specified source URI, and calls the event handler function whenever it receives an event with the name specified while registering the listener.

The resource specified at the URI is supposed to return an event stream with content-type application/x-dom-event-stream. The response could contain a series of events (each with a name and payload).

Differences

Both approaches let the server send chunks of data over a possibly long-running connection, and let the client process each chunk of data as it arrives. But the similarities end here.

• Connection management: What I liked most about server-side DOM events is the simplicity. In stead of forcing the script take the responsibility of making sure that the connection is open, with the event source approach, the browser will be responsible for reopening the connection whenever it is dropped (of course, based on some browser policy - such as waiting for a few seconds before attempting to reopen, or not attempting to reopen based on error conditions, etc). On the other hand, with XMLHttpRequest, the script developer has to deal with these conditions. IMO, this is the single biggest drawback of XMLHttpRequest’s onload handler.
• Data vs Events: With XMLHttpRequest, the response is just data carried as a part of a multipart response. The format of the response is opaque as far as the browser is concerned. With server side DOM events, the server would be returing events which get raised by the browser and can be handled just like regular DOM events. This opens the door for the server side to return regular browser events. The current draft of Web Applications 1.0 does include an event class field that could be set on each event, and this field can be mapped to browser side event interfaces including UI related and input events (such as keyboard events). Although the draft is not very clear on how such events would be processed by browsers, the current proposal could be used to couple server side code with browser side events. This seems awkward to me.
• Sending Requests: With XMLHttpRequest, you could use different verbs (GET, POST etc.) and fetch a multipart response via the onload handler. With server side DOM events, the event-source would (presumably - the draft is unclear) send a GET request to fetch events, in essence limiting the event-source to idempotent requests. Also note that the event-source is not tied to HTML controls like forms. So, if you want to fetch events based on user input, you need to create a URI encoding the user input (e.g. as a query string), and dynamically add the event-source element with the URI.

In any case, both approaches are on the bleeding edge, and are not cross-browser compatible - it would in fact be premature to expect such compatibility soon.