The Digg Oracle: Using the WorkerPool as well as full text search to empower the client

Brian Shaler has written an interesting application that uses Google Gears to do client side work regardless of if you are online or offline.

The Digg Oracle, Brian's application, pushes a data set down to the browser (in this case the history of a Digg user), and then the UI works on that local dataset. The application uses the WorkerPool to do all of the work outside of the main browser thread, and full text search to query the content in the database very quickly.

The benefit to this pattern is that by taking the hit of syncing data down to the client, you gain the ability to do a lot of fast client-side processing on the data. You can slice it. You can dice it. And you see fantastic performance.

Brian has a proposal on this pattern to speak at SXSW 2008, and he says:

Leveraging client-side services, web application developers will be able to push some functionality, especially repetitive tasks on small, rarely-changing datasets, onto the client. When functionality is pushed to the client, the client will generally see a substantial performance increase and unbeatable application responsiveness. This is because there will be a 1 server to 1 client ratio, as the client would be running its own server. Meanwhile, the usage of server resources for these repetitive tasks is reduced, potentially saving companies money on hardware or minimizing the effects of rapid success, known as "Growing Pains".
Give the Digg Oracle a whirl or see it in action:

We have seen a lot of interest in the WorkerPool and in Database full-text search, and we really enjoy watching the community using them creatively. Please let us know how you are using Gears components.

Building Offline Salesforce Applications

Our friends at Salesforce have written a detailed tutorial showing how to create an offline-enabled Salesforce application using Google Gears. Along the way they demonstrate Google Gears, Google Web Toolkit, and the use of Apache Axis to access through its remote Web services API. Full source code for the application is available, as well as screencast showing it in action, below:

The application itself views a set of relevant accounts, and then allows you to get detailed information about a particular entry.

The architecture that they chose looks like this:

The GWT UI logic talks to a data switch which is responsible for knowing if you are online or offline (via an explicit action) and gets data from the appropriate location depending on the status. If you are online, it will call out to the service data layer which understands how to get data from Salesforce via their APIs. If you are offline, the data will be retrieved locally.

Read the full tutorial to get the step by step walkthrough of the code, including how to use the GWT Gears library that bridges the worlds nicely.

We are looking forward to seeing your Salesforce applications work offline!

Gears Case Study: What we learned from Remember The Milk

Omar Kilani of Remember The Milk took the time to write up his teams experience in Taking web applications offline with Google Gears.

The article moves past an introduction to delve into the design decisions around an offline-capable architecture, and user messaging and presentation of state. We learn why Omar decided to go with the explicit offline mode, and then the five steps to offline conversion:
  1. Ensuring resources are available offline
  2. Decoupling the application from the network
  3. Persisting data on the client
  4. Re-creating application state from persisted data
  5. Developing a synchronization strategy.
Finally, we learn some tips and caveats from the RTM Gears implementation, including dealing with the LocalServer, the different types of offline, defensive coding, debugging, and coding with upgrades in mind.

Omar Kilani wraps it up in his conclusion:
By now, you should be itching to add offline support to your web application (we hope!). If you should take anything away from this article, it's that taking your application offline isn't as hard or complex as it may first seem, and that Gears is a joy to work with (and it'll become even easier and more fun as the project matures and is used by more applications).

As for us at RTM, we couldn't be happier with Gears. The speed at which we were able to provide offline functionality (four days from reading the documentation to a launchable implementation) is a testament to the quality, ease of use, and production-readiness of Gears. Many thanks to the Google Gears engineers for their foresight and for making this an open source project to which members of the Internet community can contribute.
Thanks to the Remember The Milk team for taking their application offline in record speed, and for taking the time to share their experience.