'Google Gears' vies to be de facto tech for offline Web apps

'Google Gears' vies to be de facto tech for offline Web apps

Summary: For at least a couple of years now, critics of Web applications like those served up by Web giants Google, Yahoo, and Salesforce.com have argued that those apps can never replace their desktop counterparts because of the so-called "off-line problem.

TOPICS: Google, Browser

For at least a couple of years now, critics of Web applications like those served up by Web giants Google, Yahoo, and Salesforce.com have argued that those apps can never replace their desktop counterparts because of the so-called "off-line problem." The offline problem is where a loss in network connectivity causes users to also lose access to their application logic and data. Today, with applications like Google Docs and Google Spreadsheets, this is indeed the case. If you're composing a document and experience a sudden loss in connectivity, not only will you lose access to Google's word processing logic, you won't be able to save your document or open up other ones. Depending on how your browser responds to a loss of connectivity, you may even lose any work done since the last "save" took place. This of course is not a problem with locally run applications such as Microsoft Office.

Google CEO Eric Schmidt may have recently downplayed Google's role as a competitor to Microsoft when asked as much by John Battelle. But with today's launch of Google Gears -- an open source technology designed to make the offline problem a problem of the past -- Google is clearly taking a giant step towards leveling the playing field between locally-run (desktop) and Web-based applications. Provided Google's proverbial "Office 2.0" applications are eventually enabled for the capability (they're not right now), the complexion of the Office marketplace (and the application marketplace in general) is poised for a sea change. Given Google's approach to application delivery and business models, companies such as Microsoft may have their hands forced in terms of reconsidering everything from the architecture behind their existing solutions portfolios to the licensing costs for those solutions.

Regarding the Google Gears announcement, I had the opportunity to interview Linus Upson (photo left), a director of engineering at Google to learn more about the technology and Google's plans moving forward. That interview can be heard by pressing the play button on the Flash player at the top of this blog. Or, you can click on the MORE button to download the MP3. Even better, if you're subscribed to my IT Matters series of podcasts (or want to be), the interview should show up on your PC and/or MP3 player automatically.

According to Upson, not only is Google announcing the technology today, it's open sourcing it under the new BSD open source license in an effort to establish it as the standard for offering offline functionality to Web applications.

The technology consists of three primary components. First, a local "server" which is not really a local Web server but rather a means for capturing all of the Javascript and HTML-based logic that drives the functionality of an application. Second, a local database using the open source-based SQLite for persistence of any data associated with the offline functionality. For word processing, one record could theoretically hold the entire contents of a document. For something like Google Reader (an RSS reader app from Google and, in a proof of concept, the first to take on the offline capability using Google Gears), one record might hold an RSS item. To the SQLite project, Google also contributed the necessary Javascript APIs for accessing SQLite from Javascript.

Thirdly, Google took a look at the single-threaded mentality of most Web browsers and realized that any hangup in a Javascript-based application could easily hang the entire browser (something that has happened to me several times!). So, Google solved that problem by making it possible for Javascript threads to run as background tasks.

According to Upson, where persistence of code or data is an issue, the technology is designed to create private sandboxes on a per Web app basis. So, going back to the so-called "server" from where the pages are retrieved (not "served") and SQLite, there will be partitioned instances of each for every Web application one might be running offline. Even so, Upson said the architecture is so lightweight that users shouldn't expect a heavy tax on local system resources in order to get the functionality.

Going out the door, Google is supporting the major browsers on all the major platforms including Internet Explorer, Firefox, and Safari and has pledged Opera support in the near term. Google isn't alone in launching Google Gears. It's partnering with the Mozilla Foundation and Opera (for obvious reasons) and the with Adobe. In the interview, Upson wouldn't comment on what Adobe's interests are. But I managed to track down Adobe's vice president of product management Michele Turner who told me:

Google got a hold of us and said they were coming out with an offline capability for browser-based applications and they thought it had implications for our Apollo [runtime]. So, we sat down with them and found out that if you looked across the three main components of Google Gears, we were developing identical technology to facilitate the offline component of the Apollo runtime (a component that allows Internet-enabled applications that run on the Apollo runtime to continue running without connectivity). For example, they're using SQLite and we were already incorporating SQLite into Apollo. So, now we're aligning our efforts with Google on things like the synchronous and asynchronous calls that must be made to the SQLite database in order to enable the offline capability.

Turner went on to say that Adobe intends to make Google Gear functionality more accessible to developers working with Flex and Flash action script. But she wasn't sure when that functionality would become available.

Google's Upson was not shy about his company's motives for open sourcing the technology. The idea, according to him, is to make it a standard in the marketplace now, without the need for standards bodies. With so few Web app providers offering such offline capability and with Google's war-chest behind the effort, the tech stands a pretty good chance at becoming the overnight defacto standard for running Web apps offline. At the same time, where companies have committed to an offline architecture as Zimbra has with its Zimbra Desktop (whose offline capability is powered by Java), those companies may be forced to completely reconsider that architecture if Google Gears gets market traction.

Upson and I covered a lot of ground in the interview. He described how synchronization should work when using Google Gears and talked a bit about what if anything needs to be done on the server side as well as where there's room for other innovation (for example, in the multimedia area). He also talked about how end-users would be able to manage the sandboxed partitions of code and data (for example, wiping them out the way you might individually wipe out cookies).

Topics: Google, Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • This is truely a historic moment. We will finally be getting a standard way

    to do off-line web applications. It will be great to have all of my contacts and old emails available off-line for gmail, though I would imagine it will be months before that is available.

    It will also be great to have Google Docs available off-line as well, but, that will bring up some interesting synchronization problems when you have multiple users making major changes while off-line, then wanting to re-sync. What will be the error messages be and how will it be resolved when two users have made incompatible changes??

    But, all very exciting, and great to see them using SQLite. That is one great little database.
  • Another thing, the synchronization problem is not simple. Have you seen the

    Coda project?


    It looks like they are still active with the last update released on April 11th of this year.
  • VERY Interesting

    The Adobe MS RIA shooting match just got a LOT more interesting. Especially since Google and Adobe are working closely on it. And it is Open Source to boot. Talking directly to a database with javascript is a dream come true.

    Whenever Google gets involved with something it is time to take notice and take a look at their took kit.

    Between Silverlight, Flex going open source, Apollo and now Gears, it is a very exciting time to be web a developer.
    Duke E. Love
  • how is this different?

    How is this any different from running Apache or IIS locally on MySQL or MSDE (respectively)?

    You have a server side and a client side already... why are they reinventing the wheel instead of backing the open source 18 wheeler called Apache? They could turn that thing into a jaugernaut if they backed it.
    • Becuase it's way too entrenched

      to be controlled by Google, so they in turn want to try to "hook" clients onto their offerings, something in which part of the code or process MUST go thru Google's servers.
      John Zern
      • No, Google uses both MySQL and Apache, this is a technical issue, AND,

        it is open sourced, so Google is giving up control, they have to play nice with everybody or it gets forked, especially considering the BSD license. Also, remember the SQLite is an existing open source project that Google can no more control than MySQL.

        Again, Google needed it to be an extremely light-weight small memory footprint, and a quick download. Components made for massive servers do NOT fit the bill.
        • Open source does NOT mean

          that Google is giving up control.

          How much of their custom search control have they allowed the public to see and use?


          Now, with the new GPL licensing stating that even something built on Apache under GPL3 must be mad public, Google will do their portion, the critical part, on their servers, built on GPL2 being my guess.
          John Zern
          • Google will ONLY be able to retain control if they are benevolent leaders.

            Once they start to screw people and steer it to their personal advantage over competitors, they will lose control. That is how open source works. Especially considering that they chose the BSD license.

            And, they sure will not be able to charge for it, will they??

            The other interesting thing, they are leaving MS with the ability to embrace and extend here by using the BSD license instead of GPL. They must figure that the uproar would be so great that MS will not dare screw with this.
    • Um... I donno. maybe about 50 megs?

      Which is about what it would take to DL an AMP stack. Compared to 700kb.
      Duke E. Love
    • The difference is that it needs to be extremely lightweight, AND,

      Apache and MySQL are optimized for huge loads with thousands of connections serving thousands of users. We need something to serve a SINGLE user, that has a TINY memory footprint AND is so small that it can eventually be part of the browser.

      That is Gears. Really pretty smart.
      • Sort of...

        Apache is used on Googles desktop and it is used for a bunch other apps, all pretty light weight. EX: My Asus MB came with a firewall that Admin'ed using Apache. It has about a 3-4 meg foot print. My Mysql server is using 6 megs right now and 4.0 used to use just 3 megs and change.

        My take on it is that they move away from the entire client server paradigm and just have it be a browser plugin that runs AJAX type apps with DB support. And then there are firewall issues and what not to worry about. It is meant to compete with SilverLight and Apollo.

        Like you said. It was a very smart move.
        Duke E. Love
        • I think that this will reduce the bandwidth and server load for Google too,

          at the same time speeding up the applications, even when connected. This will change the way web developers think. It is brilliant, in that web developers will be able to speed up their web applications, and add off-line capabilities with not very much work. But, imagine the reduced server load for Google if they can get a significant number using this.

          But, it needs to grow with time to be better environment than just AJAX. Should it also include sandboxed versions of Python? Ruby?
          • It is brilliant.

            I was thinking about this a lot today. Basically it is an app server that leverages existing skill sets namely Flash, JS, (X)HTML, DHTML, that is a browser plugin, with a tiny footprint, that talks to a *very capable* embedded database using.

            >>But, it needs to grow with time to be better environment than just AJAX. Should it also include sandboxed versions of Python? Ruby?

            If you think about it. JS is the obvious choice. People already know it. The learning curve isn't even nearly as steep as Flex. It is mature (except for the cross browser crap). It is OO, standardized, extendable and there are a bazillion OS Library's for it (YUI, Google, SPRY, JQuery etc). Hell, Google got it to talk to a database. And if you remember Netscape used it as it's server side scripting language for its web servers back in the 90's.

            Sure it is not as pretty as Ruby, or as easy as Rails or CF but given the above reasons it seems to be the logical choice. People can start developing on it immediately and that is what is going to get the developers mind share in the short and long run... while people a learning Flex and ActionScript or trying to get the Beta of Silver Light to work, people will already be cranking out Gears apps... Real smart move. Typical Google thinking: Smart and simple.
            Duke E. Love
          • Right, I am 100% behind Java Script for the first rollout, but, I think

            that eventually, it might be great to have some kind of a Ruby framework that would use the same Ruby code on the server and on the client when off-line. But, for now, that will be too heavy and contradictory to this being as lightweight as possible. We have to give it a couple of years.

            Also, what is the best way to do 3d rendering of streaming data for applications like Google maps or gaming. We eventually need an OpenGL engine built into the browser.
          • I agree..

            Gee read my topic just reinvention...
  • This is Scary--Big Brother is coming!

    While a lot of people are excited about this technology, I am not. I don't like where it is headed. It is not enough that Google for the most part has access to our searches, knows what we are doing on the internet, runs many of our desktop searches, our RSS readers, our email, etc., etc. Now they want to have control of our business and private documents, and all our applications. What irresistable opportunity to spy on us! Throw in some secret government agency who may make Google divulge everything about us and I think it is too much of a temptation to be resisted. Am I the only one concerned about this loss of privacy?

    • Google and others will be out of business in a flash if they do not respect

      privacy. Remember that Google was also the ONLY one to stand up against the Bush administration and refuse to give out web queries willy nilly.

      But, we trust banks to not give out our financial information, we will have trusted providers that trust to keep our documents private. But, we DO need regulations and penalties for those that use our personal information inappropriately.
    • What do you mean? Big Brother is HERE and it is Google.

      You that is scary? Check this out:


      Duke E. Love
      • The're everywhere!

        Excuse me, I think I will close my window blinds.
  • Thanks to David Berlind

    ZDNet's coverage of cool tech stuff is great! Keep up the good work.