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.
Currently Event is a flat structure of name/value pairs, with Pushlet-specific names prefixed with p_
This may be enhanced as follows:
The pushlet protocol and -clients support a publish() method to publish events remotely but there are additional features.
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). "
Facilitate configuration in user-supplied dirs
As configuration files like pushlet.properties 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.
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.
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 cache.properties. 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).
WS specifies notification through callback. See if we can use pushlet streaming to support WS clients behind firewals/NATs.
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 rpc.properties.
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.
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.
Improved and simplified most of the v1 examples.
Provide administrative pages to pushlet.war.
Provide an easy way for to publish Events remotely to the Pushlet server.
The following enhancements over v1.0.0 have been realized
The protocol and Event structure has been completely revised.
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).
Enable configuration of Pushlet protocol parameters
Done. pushlet.properties can be used to set various parameters like timings or even enforce the entire server to run in pull mode.
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).
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.
Done. Pushlets have been used in a J2ME app on a Nokia 6600 in the GeoSkating project. See client/j2me in the distro.