Since I wrote my What is Google Building? I've seen lots of interesting responses to it in my referrer logs. As usual Jon Udell's response gave me the most food for thought. In his post entitled Bloglines he wrote

Finally, I'd love it if Bloglines cached everything in a local database, not only for offline reading but also to make the UI more responsive and to accelerate queries that reach back into the archive.

Like Gmail, Bloglines is the kind of Web application that surprises you with what it can do, and makes you crave more. Some argue that to satisfy that craving, you'll need to abandon the browser and switch to RIA (rich Internet application) technology -- Flash, Java, Avalon (someday), whatever. Others are concluding that perhaps the 80/20 solution that the browser is today can become a 90/10 or 95/5 solution tomorrow with some incremental changes.
...
It seems pretty clear to me. Web applications such as Gmail and Bloglines are already hard to beat. With a touch of alchemy they just might become unstoppable.

This does seem like the missing part of the puzzle. The big problem with web applications (aka thin client applications) is that they cannot store a lot of local state. I use my primary mail readers offline (Outlook & Outlook Express) and I use my primary news aggregator (RSS Bandit) offline on my laptop when I travel or in meetings when I can't get a wireless connection. There are also lots of dial up users out there who don't have the luxury of an 'always on' broadband connection who also rely on the offline capabilities of such applications.

I suspect this is one of the reasons Microsoft stopped trying to frame the argument as thin client vs fat rich client. This discussion basically is arguing that an application with zero deployment and a minimalistic user interface is inferior to a desktop application that needs to be installed, updated and patched but has a fancier GUI. This is an argument that holds little water to most people which is why the popularity of Web applications has grown both on the Internet and on corporate intranets.

Microsoft has attempted to tackle this problem in two ways. The first attempt is to make rich client applications as easy to develop and deploy as web applications by creating a rich client markup language, XAML as well as the ClickOnce application deployment technology. The second is with better positioning by emphasizing the offline capabilities of rich clients and coming up with a new monicker for them, smart clients.

Companies that depend on thin client applications such as Google with GMail do realize their failings. However Google is in a unique position of being able to attract some very smart people who've been working on this problem for a while. For example, their recent hire Adam Bosworth wrote about technologies for solving this limitation in thin clients in a number of blog posts from last year; Web Services Browser, Much delayed continuation of the Web Services Browser and When connectivity isn't certain. The latter post definitely has some interesting ideas such as

the issue that that I want a great user experience even when not connected or when conected so slowly that waiting would be irritating. So this entry discusses what you do if you can't rely on Internet connectivity.

Well, if you cannot rely on the Internet under these circumstances, what do you do? The answer is fairly simple. You pre-fetch into a cache that which you'll need to do the work. What will you need? Well, you'll need a set of pages designed to work together. For example, if I'm looking at a project, I'll want an overview, details by task, breakout by employee, late tasks, add and alter task pages, and so on. But what happens when you actually try to do work such as add a task and you're not connected? And what does the user see.

To resolve this, I propose that we separate view from data. I propose that a "mobile page" consists both of a set of related 'pages' (like cards in WML), an associated set of cached information and a script/rules based "controller" which handles all user gestures. The controller gets all requests (clicks on Buttons/URL's), does anything it has to do using a combination of rules and script to decide what it should do, and then returns the 'page' within the "mobile page" to be displayed next. The script and rules in the "controller" can read, write, update, and query the associated cache of information. The cache of information is synchronized, in the background, with the Internet (when connected) and the mobile page describes the URL of the web service to use to synchronize this data with the Internet. The pages themselves are bound to the cache of information. In essence they are templates to be filled in with this information. The mobile page itself is actually considered part of the data meaing that changes to it on the Internet can also be synchronized out to the client. Throw the page out of the cache and you also throw the associated data out of the cache.

Can you imagine using something like GMail, Google Groups or Bloglines in this kind of environment? That definitely would put the squeeze on desktop applications.