Google gears and the online state dilemma

As I mentioned in my previous post I've been working with Google Gears as of late. Being a greenhorn to this technology (as nearly everyone is since it's pretty new) I found myself considering some fairly serious design questions. The most interesting was "how do I tell if a user is in offline mode (pages and data cached) but has the ability to switch over to online mode?"

Now of course whenever you talk about "modes" in an application it is natural to think about a state machine. That gets a little dicier with the new paradigm introduced with Gears. Since gears runs purely in javascript with a little interaction with the browser plugin, I decided that making an AJAX request for a file that doesn't get cached (as defined in my gears manifest file) was best. If I got the proper contents of that file then I knew the person could swap to online mode, if not then I know they aren't connected. Simple right?

So I thought. Once I whipped up my code I could offline and online my pc and the app was stateful, except of course for a little lag that the ajax request took to timeout when it wasn't ever going to get a response from the server. I included validation based on state to see if I would let the user remove their cached pages and get the online one and everything was happy.

Then I decided to take a look at what I'd done pretending to be a non-technical user. I offlined my app and then watched it. During the lag I noticed that the app state was still online (meaning you could validly switch to online mode) because the first AJAX request hadn't failed yet. So I thought to myself "what if the user took this literally and assumed they were connected via wifi or something and tried to go online?"

The answer: DEATH. Ok not really death but my state machine happily checked its state, saw that it was online, removed all the cached pages and tried to get at the online version of the page. This of course resulted in a 404 as the user wasn't actually connected. No good. My first instinct was that I had to prevent this from ever being a possible scenario because a user would probably freak out.

The half-measure I took to do this was to break out the cache-removing code and not include it on the manifest. Now the user can attempt to remove their cache, but if they aren't actually online they won't find that page and get a 404, but they can back up and the app is still happily serving up cached content while they continue to be offline.

I'm happy with this but not completely. It seems to me (at least so far) that there's no way to conquer this part of the paradigm shift that gears introduces into web applications. No matter how you code around it, the web layer always has a degree of latency associated with it that will allow a window for 404 messages. I hate for the user to see that. I'll update if I figure out a way around this loophole, please comment if you know one ;)