Development Roadmap

This document provides the Pushlet development roadmap. It lists features to be developed and their development status. This lists the status as on $Date: 2007/11/24 11:00:35 $. The document has two main sections: the "To Do" section lists the "wishlist" of features. The "Done" section outlines developed and thus available features. See also the SourceForge tracker.

To Do

Event Structure Enhancements

Currently Event is a flat structure of name/value pairs, with Pushlet-specific names prefixed with p_

This may be enhanced as follows:

Event Publishing

The pushlet protocol and -clients support a publish() method to publish events remotely but there are additional features.

Internet Explorer 2-Connection Limit

This is a nasty issue first Reported by Shimon Crown.

"I have found a strange bug when more than 1 IE 5.x browser is used to access the pushlet from the same client. The first two browsers access and report the pushlet results very nicely. The third one justs hangs. If you close one of the browsers, that is working then the third browser starts working (providing it hasn't timed out). Curiously this doesn't occur with Netscape 6 (or the identical Mozilla build for that matter). "

This is a limitation for IE when using HTTP/1.1: by default only two connections can be made. When more connections are needed a Windows Registry setting has to be made.

This is (partly) solved by multiple subject subscription that can take place "out-of-band". A client can also provide a label (tag) on subscription as a string. This label is sent on events for the subject and may be used to denote for example an internal JavaScript callback function.


Facilitate configuration in user-supplied dirs

As configuration files like are accessed through the CLASSPATH, users may already override configuration properties by dropping their own property files in the appserver's CLASSPATH. In Tomcat this can be effected by dropping in the shared/classes dir.

The idea here is to allow a config.redirect property that specifies the actual user file.

Browser/DHTML Enhancements

Scrutinize the JavaScript library (need DHTML expert).

Event Routing

Currently simple topic-tree string matching. See if this mechanism can be extended.

Possibly the current mechanism extended with multiple subject subscription is ok.


Provide a pushlet.war that doesn't need to be changed (goes together with Event Publishing enhancements)

Since the remote event publishing through POST works this is already possible. Still enhancements needed.

Event State / Caching

Provide a way such that subscribing pushlet clients can first receive the current state (e.g. all current exchange rates) followed by regular notification updates.

The idea is that the Dispatcher will have configurable caches for indicated topics. This will be configured through Per-subject one of two cache types can be specified: key-based (HashMap, e.g. for the current values of let's say stocks) or FIFO-based (last N events).

Web Services

WS specifies notification through callback. See if we can use pushlet streaming to support WS clients behind firewals/NATs.

RPC Support

Add support for RPC calls in the Pushlet protocol.

RPC can facilitated with a special control event (p_rpc) that specifies a handler/method to be invoked on the server. The developer should be able to supply handlers (Java classes) on the server and configure them in a file, like

For example each handler could have a unique string and a classname. The return value could be the existing (enhanced) Event. Basically this feature would allow a service similar to XMLHttpRequest.

Additional Client Types

Try to support Flash natively, i.e. not through JavaScripting.
Prototyped Flash with Pushlet in "pull" mode works!. Also Java mobile clients (J2ME).

Python/Ruby and friends.


There is no security currently. See how security can be added non-intrusively.
Tricky issue. At least v2.0.0 allows a developer-supplied SessionManager and Dispatcher, such that custom security/authorisation may be enforced in some cases.

Need to add some parameters to allow/disallow e.g. inet domains to publish events.


Get exact figures for limits and make enhancements. A generic Pushlet server with NIO is a possibility.

Aim for linear scalability.

An interesting enhancement would be the use of Java Non-Blocking I/O (NIO). This may be practically realized in Tomcat using the Cheetah NIO Connector under development.

If Pushlets are to be used on a large scale it may be advantageous to develop a dedicated Pushlet HTTP server. This server would appear as an ordinary HTTP server towards clients but could be optimized for long-lived connections, for example by using configurable thread pools and assigning a "thread-per-event" i.s.o. a "thread-per-connection" as most web-servers do.


More examples.
Improved and simplified most of the v1 examples.


Provide administrative pages to pushlet.war.


Event Publishing

Provide an easy way for to publish Events remotely to the Pushlet server.

Enhanced Pushlet Protocol

The following enhancements over v1.0.0 have been realized

The protocol and Event structure has been completely revised.

Browser/DHTML Enhancements

In particular Safari and Opera.
Done. Pushlets work in both of these browsers. Safari only in "pull" mode.

Enhance web-page integration (e.g. IFRAME).
Done. Pushlets can be embedded by a JavaScript call (p_embed()). This uses an IFRAME. The development of DHTML will be significantly easier through the use of a Pushlet JS library. See the JavaScript libraries (CVS). No wait-cursor is shown in most browsers.


Enable configuration of Pushlet protocol parameters
Done. can be used to set various parameters like timings or even enforce the entire server to run in pull mode.

AJAX (XMLHttpRequest) Support

There is a lot of buzz on AJAX and in particular XMLHttpRequest, a browser DHTML (DOM) feature that allows asynchronous XML RPC calls. Example applications are Google Suggest. Here is an introductory article on AJAX (worthwhile read).

Pushlets have similar characteristics as XMLHttpRequest like asynchronous messaging. There could be an ideal marriage between the two technologies: XMLHttpRequest could be used as the front-end library to the back-end Pushlet server. On the client-side, the JavaScript library (js-pushlet-client.js) could be altered to use XMLHttpRequest i.s.o. hidden IFRAME/FRAMES. Advantages are clear:

A first investigation learned that this approach is viable and that no server-side changes are required. There are some specific issues though:

Done. Since version 2.0.2 Pushlets support AJAX in "pull"-mode with format="xml-strict". An AJAX JS client library (ajax-pushlet-client.js) is available.

Additional Client Types

J2ME clients.
Done. Pushlets have been used in a J2ME app on a Nokia 6600 in the GeoSkating project. See client/j2me in the distro.

Just van den Broecke - $Date: 2007/11/24 11:00:35 $ - $Id: roadmap.xml,v 1.12 2007/11/24 11:00:35 justb Exp $