It was decided early in the design cycle that the ICEpush integration for GWT should be an wrapping of the ICEpush Javascript API. However, the exposed GWT push API must look more like Java style operations rather than Javascript ones. In this spirit, a GWT application will be able to register Java Listeners to push groups. I expect the have an interface called PushEventListener that will provide a single callback method onPushEvent(). The implementing class can then provide the application logic that should be executed when a push event is received.

It seems that wrapping the provided Javascript API into a LIstener pattern is not as easy as at first anticipated. It is desirable to abstract the notion of a PushId from the end user of the API. Thus the Listener must hold some state to keep the push id from the developer. As such I changed PushEventListener from an interface into an abstract class that store the push id and groups. This will allow the integration controller to maintain the list of registered groups and also make it possible for listeners to be removed from the context.

The suggested method for calling native javascript from GWT is to declare methods as 'native' and then write javascript code in the method body. The first step of the integration is to wrap each of the push javascript api calls into GWT native calls. Specifically the following methods will be wrapped:

ice.push.createPushId()
ice.push.addGroupMember()
ice.push.removeGroupMember()
ice.push.register() [this method will take different paramters - push id and a GWT pushEventListener]

I decided not to wrap the ice.push.notify() method until the security issues had been sorted out.

The high level GWt integration methods GWTPushContext.addPushListener() and GWTPushContext.removePushListener() will be compositions of the previously mentioned native calls.

In an effort to make the integration testable, I am extracting the native methods out of the class GWTPushContext and placing them in a new class which extends the interface IcePushClientLibrary. That way the IcePushClientLibrary methods can be mocked by JMock and the GWTPushContext class can be tested.

Started to extract the Push Integration code from the Chat application into the integrations project. The 4 integration classes are now being bundled as a jar with a GWT module descriptor file included. This jar can then be added to a project and used. (requires a single line entry in the end user's gwt module descriptor to inherit the client side code.).

After some issues involving complexities with the low level API provided in the GWT integration thus far it became apparent that a higher level API using a command queue might be useful to provide to developers. The reasoning for this is as follows:

1.) Several of the low level optimizations in the Push framework are hidden from the developer - how ever they have side effects which the developers must be aware of. A noteworthy example is how ICEpush buffers notifications. If more than one notification is triggered in a short period of time, the JS callback may not actually be executed on a one to one basis. This behavior is actually desirable for performance but can be unpredictable if the application developer is not aware of it.

2.) A command pattern is a robust design pattern for receiving and handling different types of updates.

More details to come

Added a simple sample application that is an extension of the greeting application that the GWT webAppCreator utility creates.