Language-Specific VM's as a Google Gear?

Has Google Gears or Adobe AIR team considered adapters to language-specific VM's? E.g. client side VM's (for instance, like Rubinius) hooking up to the Gears runtime? The idea being that if you could hook up to a VM running on the client, it could be used to interpret the implementation-specific code -- E.g. a Rubinius VM running on someone's machine, when hooked to Gears, could enable Ruby code/ or ERB in a page in the offline cache, to be successfully interpreted on top of Gears. The VM an individual chose to install would be a separate install outside of the Gears runtime, but would need an api to connect to the Gears runtime.

Wanted to throw out the idea and appreciate any response-
holtonma (at) gmail (dot) com

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.