Offline enabled web apps -- Google Gears, Adobe AIR

Wondering about Gears and AIR... starting to toy with both a bit more these days... maybe the following is a worthwhile topic... related to ideas on how to best structure an offline-enabled (AIR or Gears) web app from scratch. Anyway, wanted to throw out a blog post. Feel free to respond to me here or at holtonma (at) gmail (dot) com.

Since neither AIR nor Gears runtime obviously has any interpreter for server-side langs, like Ruby for instance, and is just a straight manifest (either running on top of WebKit with Air, or running on top of the Gears runtime)... you have at your disposal HTML + JavaScript + SQLite on the client. (or additionally Flash/Flex with AIR, but I personally don't plan on using those initially)

Am wondering, if I'm building another webapp from the ground up (i.e. not extending functionality), it seems like there would be an advantage, where possible/pragmatic, to structuring my app as HTML+Ajax throughout, and trying to remove wherever possible any references to eRB, PHP tags, CF tags, et al inside the page. This way you could keep your Views DRY (pretty much straight HTML and JS), and within JavaScript you could, for instance, have a Factory to detect online, high-latency, or offline, then direct the code to either run an Ajax query to the server-side store, or to the local SQLite db. It would also, to an extent, disconnect the server-side Model from the implementation -- that is, you could have server-side Model code on the server in Ruby, Python, CF whatever you wanted.

By loosely coupling the server-side to client side with HTML + JS seems to afford an opportunity to more readily adapt to runtimes like Gears or AIR.

Is that a fair analysis? Am I missing something? Was curious to hear the thoughts of someone who knew more than I on this topic, so please, fire when ready.