http://www.informationweek.com/blog/main/archives/2008/10/persistence_is.html

http://jchris.mfdz.com/code/2008/10/standalone_applications_with_co

Of course, this problem will lessen when we get wifi on airplanes! Whenever that is…

I was at a conference a few weeks ago and wanted to update my Google Notebook session at the end of the last day. At 5pm sharp, the wireless shut down and Google Notebook became useless. I lost my context, and my notebook. Darn.

One of the difficulties, as always, is the unbelievably sucky “browser” model that we are forcing applications to live in. Another view of this problem would be the “time-travel button” problem (ie, “the go to the previous page button”). For many web 2.0 apps, if you traverse away from the page the app is running on by clicking a link, when you come back, you don’t get dropped back into the state you were in when you left the “app”; the “page” is basically reloaded anew. A smart web 2.0 based app will do things like leave state in a cookie or in a hash tag in the location bar, and then use that to re-orient itself in time, so you have the appearance of coming back to where you were. Takes work at the application level to make this scam viable.

In much the same way, reloading a “page” on startup is going to go through the same motions. But now the problem is that if you’re off-line, that app probably isn’t going to be able to re-orient itself, because it was probably pulling stuff from the web to do that in the first place.

To do this right means having reasonable Gears or other local persistence in place, with the application actively taking advantage of it.

The alternative would be for the browser to actually remember the state of the “page” transparently. This isn’t just remembering, for instance, the current version of the DOM being displayed; it’s the state of the JavaScript runtime. Almost do-able, I think. You’d need to define what happened to things like XHR requests which were outstanding during the “page save” (probably ignore them – don’t try to “revive” them during a “reload”). Seems like a worthy experiment to try, but I’m guessing it wouldn’t be a pretty picture. We did this sort of “freeze the runtime state so it can be revived later from a cold start” in Smalltalk. Do-able. But not all scenarios were revivable.

In the end, the blame needs to be laid on the app developers, not the browser developers. Don’t think this is really fixable in the browsers, as we know them today.

Or, you could say the blame is on the browser developers not giving us a suitable application runtime platform. While I think there will always be some amount of work an application will have to do to make it cold-start revivable, the runtime platform could make this a little easier than it does today. For instance, exposing specific “I’m about to suspend” and “I’m reloading” events sent to an application.

But that aside, suspend/hibernate is the best solution I have found so far.

As soon as you do more (most cases) then it gets harder. Look at how well Zoho has done though. Their office suite continues to do more and more offline, including their Mail product.

Offline isn’t “free”. It comes at a price, that of rethinking your architecture. But, our expectations of what Web applications can do continues to change, and that will include expecting apps to work offline.

Cheers,

Dion Almaer

Formerly, Gears team
Currently, Mozilla