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.

"The Power of Google Gears -- Part I and II"

For those of us interested in Google Gears:

http://www.onlamp.com/lpt/a/7055

http://www.onlamp.com/lpt/a/7057

Google Gears - Performance Out of the Box

Google Gears was released last week and it's been hugely exciting to get a look at this api, along with some of the apps people have come up with already.

Google Gears API

Obviously many of us had been looking at Adobe Apollo for awhile, and Google Gears is of the same mindset -- but even more encouraging it was released under the very liberal BSD license, which only adds encouragement to those of us excited about the rapid advancement of technology. It will be exciting to see the rapid progression of this 'platform' for offline integration of web applications. The community of web developers has so many ideas, and Google's release of Gears to the community in this manner will no doubt generate many ideas that will find their way into the next release of Gears is my only guess.

As an Ajax developer where I am particularly interested in Gears is in terms of performance, over and above online/offline synchronization as a feature. While the two go hand in hand synchronization has a specific place in many apps (internet connection dropped, queue-ing work completed offline, etc), I feel like the performance aspect of Gears with this offline database and client side file cache will become huge. I am looking forward to seeing many engineers benchmark their web applications once they have become enabled with and optimized for Gears.

Developing with Google Gears in mind, could become like Ajax has become the last two to three years. What I mean when I say that is that there are significant performance benefits that can be gained by limiting the number of trips to a server (both web and database), and processing items in batch. We have already seen this with regards to Ajax applications sending bits of data to the server rather than whole page requests, and this takes it a step further. We now have a larger set of boundaries to work with as web developers. We can choose how much to update, when to update, along with a client side failsafe. Having the cross operating system desktop intermediary is the enabler here, and the deployment potential of a large player like Google are obvious.

As Google continues its collaboration with Mozilla Firefox (I can't wait for Classes in Javacript 2.0 by the way!), and open source libraries like Dojo, it will become easier to integrate these offline caching and synch-ing paradigms into our development practices.

All of this enables richer, more responsive user experiences for the end user. It enables exciting new architectures for web applications. The future is surely bright for the paradigm of web-based applications growing in performance, capability and reach.

VirtueDesktops for Mac + Dojo.sql ENCRYPT(?) screencast

This is wild. For those of us awaiting the release of "spaces" in Mac OS X Leopard, in the meantime you can download VirtueDesktops
http://virtuedesktops.info/index.php/downloads/
http://virtuedesktops.info/index.php/about/

I caught the use of this during a screencast by Brad Neuberg (http://dojotoolkit.org/offline), and have been playing around with it on my Mac today. You can see him use Virtue Desktops in this screencast where he efficiently moves to different desktops. IMO, it's a great way to efficiently organize my machine. Thanks for the link, Brad!

Incidentally, the screencast is related to encrypting data with Dojo Offline. If you're interested in that screencast it is here, it's pretty sweet:
http://codinginparadise.org/video/dot/dot_encryption_small.mov

On the Google Gears mailing list Brad mentions that enabling transparent encryption and decryption will be in the Dojo Offline port that runs on top of Google Gears in about 2 weeks. Looking forward to seeing that high level lib on top of Gears!