In the web development space everybody knows how a browser generated event can be dispatched by the server: a simple click on a link requests a new page or sends an AJAX request to the server; these are client-sent events. These days we can hear a "new" concept: "server-sent events" related to Comet.

But what are server-sent events?

The Wikipedia gives you a clue :

Called server-sent events, it attempts to avoid the disadvantages of other Comet transports, while making Comet applications much more straight-forward to implement, both on the server side, and in the browser-side JavaScript. The server-sent event portions of the HTML 5 specification stipulate both a new HTML element, event-source, and a new data format, called the DOM event stream. JavaScript can be used to attach callback functions to multiple types of events.

In this case The Wikipedia is not the best place to learn, the Web Hypertext Application Technology Working Group (WHATWG) shows this better:

This section describes a mechanism for allowing servers to dispatch DOM events into documents that expect it. The “event-source” element (HTMLEventSourceElement) provides a simple interface to this mechanism.

In a few words, server-sent events are “events” sent to the client using a permanent HTTP connection with a content type “application/x-dom-event-stream”. Server “events” are simple text like these:

Event: server-time

data: [time on the server]


Event: the-answer

data: 42

This will send two events to the browser, and it's possible to catch them as DOM events. The following JavaScript example listens for the "server-time" event, and alerts the content.

document.getElementsByTagName("event-source")[0]

        .addEventListener("server-time", eventHandler, false);


function eventHandler(event)

{

    // Alert time sent by the server

    alert(event.data); 

}

In this example, taken from Arve Bersvendsen’s blog a member of the Opera crew, the event type is user defined (standard events could be supported).

May be you know that since 2005, the Web Hypertext Application Technology Working Group (WHATWG) is working to include this approach as part of the HTML 5 specification. May be you know Opera 9 is the first browser supporting this new technique. And finally may be you know this "new" technique is ignored by any other browser... two reasons:

1. HTML 5 is a draft


2. Microsoft Internet Explorer has largely ignored the W3C DOM Events standards (neither IE 7). Any plans to support the old (year 2000) W3C DOM Events Level 2 specification?

May be you say "Bad news, this technology is amazing to build web applications with server-push a.k.a Comet requisites".

Don’t worry, server-sent events is a kind of Comet, you can ever use server generated JavaScript to execute client code using Comet techniques. Of course this is similar but is not the same.

Can we use server-sent events now?

Yes!

ItsNat , a new open source AJAX based Java web application framework, provides a server-sent event technique using W3C standards. ItsNat sever-sent events implementation is not of course standard but it falls near the proposed standard (in fact ItsNat version is more advanced).

ItsNat simulates a Universal W3C Java Browser at the server, the server mimics the behavior of a web browser, containing a W3C DOM Level 2 node tree and receiving W3C DOM Events fired by the browser using AJAX requests.

With this foundation is not difficult to create in the server a Java W3C DOM event (for instance a mouse “click” event) and dispatch to a server based W3C DOM element as target. ItsNat automatically sent this event to the browser using Comet techniques, converted to a native event and dispatched to the client symmetric target element. If the target DOM element in the server is listening this type of event (a listener was registered in the server), the client forwards again the event to the server.

With this technique we can simulate user actions from the server, opening a new world of uses:

* Server based functional web testing with no external tools

Using the real browser and the power of Java. Server based functional web testing has the following advantage: as the test code is in the server, can test whether the business data is correct (data was created, updated and removed correctly). With ItsNat the view can be tested checking the server DOM tree too.

* AJAX Bookmarking

A permalink system may be defined to save concrete states of the AJAX web application. When the AJAX application is loaded using a permalink the server can simulate the necessary user actions to drive the application to the desired application state on load time.

* Add yours…

ItsNat goes further introducing an alternative "server-sent events" technique: W3C DOM events fired by the server dispatched directly to the server W3C DOM without browser interaction, following the W3C DOM Events standard including “capturing” and “bubbling” phases. In this case no browser is used, no network latencies, synchronous execution (this avoid the typical waits when testing an asynchronous AJAX application using the browser mode).

On testing both modes are complementary (source code is basically the same), if the "no browser" test fails of course the "browser based" test would fail.

The “no browser” mode is valid to make AJAX applications “searchable” by Google/search engines, because the initial state is built in the server with no browser interaction (no JavaScript is used).

Follow this link to see server-sent events in action.

What do you think about these server-sent events techniques?

What kind of applications can be beneficed by server-sent events or server-push (Comet) in general?

What problems do you find when testing or bookmarking an AJAX application?

How do you achieve your AJAX application is Google (Yahoo etc) searchable?