Ruby on Rails with Google Gears
Prelude
This post is just my head throwing ideas about. Non of which are fully formed, nor fully investigated.
Intro
Today Google labs spitted out an early “plugin” for Internet explorer and firefox to make websites viewable and interactive offline. This isn’t entirely new as Apollo offers something similar. However, this is interesting considering Google is one of the kings of webapps. With Gmail, Google Calender and Google Docs all obviously the target for this technology I doubt that it would fail spectacularly.
Very brief and rubbish Gears overview
First off, there are two main components to Gears. The webserver and the database. The webserver is pretty simple to get our heads round, it essentailly caches pages that us as developers tell it to. For me the most interesting parts is the database.
The Gears Plugin that the user installs includes a fully relational SQLite database. As developers we can interacted with it by passing SQL commands via javascript. Yes thats right… we interact with it by using javascript code such as
var rs = db.execute('select * from Demo order by Timestamp desc');
The benifits of this are pretty interesting. For example webservers technically don’t have to store information at their end, ever, just relying upon the users own store.
I feel however the most use of such an app would be for something like gmail, where when you are offline you write and send an email with gears facilitating the actual sending of the email when the internet becomes available.
So how would Rails fit into all of this?
I love writing webapps in rails. Its quick, easy and Ruby is lovely to write. So could developing a Rails app with gears functionality be a possibility without having to drop into insane javascripty-SQL-type goo every time?
The answer in my opinion is yes, but it won’t be easy.
Here are the major barriers in the way to making a my ideal acts_as_gears type plugin.
- The plugin should be able to convert Ruby into javascript for offline controllers and model interactions. A massive undertaking (possibly recreating active record in javascript.. shudder).
- Creating the user’s local database and linking each column with the live database columns would be essential if we wanted to do any sort of syncing.
- The automatic creation of database syncing methods in javascript and ruby.
- Creating a seamlessness of data origin in views. For example, a table of information should be able to be printed out on one page irrespective if data came via the live or local database.
- The views should only have to be writen once, with of cause different javascript payloads.
- Loading and unloading of data needs and state management.
Anyway that’s what’s on my mind right now, a half baked whirlpool of rails, javascript and gears.
June 1st, 2007 at 3:33 am
nice post. Thank for the info.
I don’t believe it will always be that “webservers technically don’t have to store information at their end, ever, just relying upon the users own store.”
There will be many cases (performance being one of them) where we as developers will engineer the ability to handle requests in a way that was much more efficient in the client-server environment. For instance, in the same manner that Ajax submits only bits and pieces of data to the server as an efficiency improvement over traditional-submit-the-whole-page…
Gears/Apollo grant the new technique of submitting/saving information to local, then submitting to the server to synch at the developer’s discretion. This could be very powerful in terms of the perceived performance of web applications as they will react in an increasingly more responsive way (no need to wait for server response in many cases )
June 1st, 2007 at 3:08 pm
From my limited uderstanding of Google gears, I believe you’re looking to make something too complex for it to be useful with rails. If you’re having to replicate full databases on the client you start running into all the deployment issues you were trying to avoid by making a web app. Might as well write a real desktop client then or a completely Javascript application. However it would probably be quick to create helpers in rails to leverage the caching facilities in gears so you can still consult data offline as well as limited use of the local DB to allow saving of form ’submissions’ (i.e. email, comments etc..) on the client until a connection is reestablished and they are committed to the webserver. I’m talking about viewing this from the client perspective, not replicating the server to the client. Allowing network connections to be dropped without causing big pains.
June 1st, 2007 at 5:45 pm
I think this is interesting, after all it came up in my Google.
I will be exploring this and psot back anything I dsicover, hope you will as well.
June 1st, 2007 at 6:52 pm
Yes Decklane, it is too complex. Just throwing around the idea.
The thing being that helper methods to produce javascript which acts as database controllers can only really be useful and resuable if there is an activerecord type thing going on in either rails producing the javascript (with all the sql) or within the javascript itself.
Alas, its a weekend task to explore. I really haven’t given much thought to any of this.
June 5th, 2007 at 11:58 am
Hey there. Interesting stuff.
There is a Ruby to Javascript library that Paul Battley wrote:
http://po-ru.com/diary/convert-ruby-to-javascript/
Using REST is probably best bet for syncing or something like acts_as_syncable:
http://www.eribium.org/?p=119
I don’t really have a need for Gears at the moment but I’m keeping an eye on it. I reckon there would be some traction with a plugin for it.
June 29th, 2007 at 2:58 am
I think the potential for this technology is absolutely amazing. I look forward to using it in the future..
August 19th, 2007 at 12:35 am
hi i enjoyed the read
September 18th, 2007 at 10:28 am
Hi all!
Very interesting information! Thanks!
Bye