The desktop Higgins 2 selector client runs synchronization process each 30 (N) seconds. But it's not the best way to sync the data, at least on the mobile platform.
We would use server push (comet) technology for delivering notification (signal) about new data on the Attribute Server instead of running synchronization process each N-seconds.
Synchronization needs to work in two directions:
a) client → server
b) server → push server → client
"a" can happen almost any time, but should happen when a context has recently been changed but not further changes are expected in the short term (we don't want to do a sync midway through updating a context's attributes).
"b" may happen only if selector is connected to push server, it should only start just "a" synchronization.
We may use Push service just for delivering notification (signal) about new data on the Attribute Server.
After starting, Azigo selector has to obtain access token and establish two connections:
- first - synchronous with Attribute Server for sync data (it will be closed, after finishing synchronization);
- second - asynchronous long-lived with Push Server for receiving notification about new data.
Than, user update password on home PC. It should trigger the following steps:
1. Azigo selectors should send new data to Attribute Server.
2. Attribute Server should send signal "context was updated" to the Higgins Push Service.
3. Azigo Push Service should delivery that signal to the other "active/connected" user selectors (on work PC and mobile) directly or by using 3rd party push server (2.1).
4. Azigo selector should start synchronization by using already implemented method ("a").
Apple supports push notification on the iPhone http://www.youtube.com/watch?v=Wf-C16xh0r4 , MS supports it on the windows phone 7 platform http://www.ditii.com/2010/03/15/push-notifications-and-windows-phone-7-series-video/ . Xtify provides similar on the Android platform http://developer.xtify.com/. Google showed push demo with Android 2.2 on google I/0 http://www.youtube.com/watch?v=dBQFXRW5ZiE&feature=channel and introduce Android Cloud to Device Messaging Framework http://code.google.com/android/c2dm/
All the above mobile solutions require to use the third party Push server (apple/ms/xtify/google), but we may review ability to develop the own Push Service by using Atmosphere http://jfarcand.wordpress.com/2010/05/14/writing-portable-html5-websocket-application-using-the-atmosphere-framework/ or Cometd http://cometd.org/documentation/resources/2.0.beta-releasenotes java frameworks or Kaazing Web Socket Server http://www.kaazing.org/ and HTML 5 Websockets http://dev.w3.org/html5/websockets/ or Bayeux Protocol http://cometd.org/documentation/bayeux/spec.
Server push also may be more effective on the desktop platform. We may develop the Push Server, which should expose WS API to the Attribute Server and work with Higgins 2 selectors directly or via 3rd party (Apple/MS/Google) Push servers (wrap communications with them).
Push demo server
This demo app implements push chat for Higgins users by using HTML 5 WebSocket http://dev.w3.org/html5/websockets/.
Please, use this how to http://rh155.azigo.net/push/index.html for testing push demo server.
The push demo server implemented by using:
- Atmosphere framework 0.6.0-SNAPSHOT https://atmosphere.dev.java.net/
- Jetty web server 8.0.0.M0 http://docs.codehaus.org/display/JETTY/Jetty+Wiki (supports Servlet 3.0)
--> GET /push_server/async/ HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: rh155.azigo.net:8080 Origin: http://rh155.azigo.net <-- HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://rh155.azigo.net WebSocket-Location: ws://rh155.azigo.net:8080/push_server/async/ --> .password#Alex4@Android@02248011: has joined! <-- ..Alex4@Android@02248011: has joined! --> ..Alex4@Android@02248011:test message from Alex on Android <-- ..Alex4@Android@02248011:test message from Alex on Android <-- ..tmpUsr@Linux i686@02092850: test message from tmpUsr on Linux. ......