9. Further Work

I am further testing the viability of Pushlets. The Pushlet framework is actually a generic Publish/Subscribe pattern with HTTP-based Pushlet clients as a special case. I am evolving the framework with the following extensions

9.1. Additional client receiver-protocols such as TCP and UDP

One interesting area is the possibility to call an applet that receives UDP messages from within the Pushlet frame on the client. This would mean that we don't keep the HTTP connection. In general clients will subscribe with a HTTP request on which they indicate through which protocol (TCP, UDP, RMI, HTTP-stream, HTTP POST) they want to receive events and in which format (XML, Java serialized objects,...). Where required the address of the receiver is specified. For example to receive XML formatted stock events through UDP on port 5001:

http://www.fluidiom.com:8080/servlet/pushlet?subject="/stocks/aex"&format="XML"&protocol="UDP"&port="5001"

With UDP a lease time may need to be specified (since the server would never know when the client leaves). If the lease is not renewed after this time the server will drop the client.

9.2. additional client sender-protocols

Currently events are generated internally or through the Postlet by using the HTTP POST request. Additional protocols such as RMI, TCP and UDP may be applied.

9.3. subject state

Currently a subject is just an hierarchical string and a client that subscribes gets no history that may have been built up. For example in a chat some discussion may have been going on. In a next version subjects will become first class objects such that when clients subscribe they may implicitly get the current state or may explicitly request the state.

9.4. multi-user

Although some multi-user applications are possible there is no knowledge or management on the server. In earlier versions I have experimented with combining multiple HTTP Sessions into a multi-user HTTP session.