With apologies to Dave Johnson, but continuing in my fine tradition of being the last to bring you news, I offer you the following commentary on the recent announcement of Google Gears. Given the breadth of coverage you’ve likely already seen on the announcement, I can’t promise anything new, but I’d be remiss if I didn’t address the question given my long running interest in offline browser persistence approaches. On to the Q&A.
Q: Before we begin, anything to disclose?
A: Let’s see. Well, Google is not a RedMonk client, and I have not been officially briefed on the Gears technology at this time. IBM and Sun, which both currently support versions of the Apache Derby database (originally developed by IBM under the Cloudscape moniker), are RedMonk customers, as is another embedded database supplier, db4objects. Neither Joyent nor Zimbra are RedMonk clients, but they host a personal site of mine and our RedMonk email respectively, gratis. I think that about covers it.
Q: For those that haven’t yet seen the news, can you summarize the announcement?
A: Well, David Berlind’s already done an excellent job describing the technologies in his post here, so I’d recommend you start there. And definitely listen to the podcast interview with Linus Upson, a director of engineering at Google; I’m not a podcast guy, but it’s worth your time.
For the link and/or podcast averse, however, the basic summary is this: Google is introducing in Gears a cross-platform set of technologies that intend to facilitate the construction of Ajax applications that can function in a disconnected – i.e. offline – state.
Q: Any applications enabled yet?
A: Just one, as far as I know, Google Reader – see the inset picture. It’s a bit klunky, in that you seem to have to press a button to go offline before you actually go offline, but it’s compelling nonetheless.
Q: What is the problem space Gears is aimed at?
A: One most of us know quite well. Try using Gmail, as an example, in the absence of a networking connection. Or Yahoo Mail. Or Hotmail. Or, well, you get the idea. While Software-as-a-Service, as embodied by regular consumer facing apps like Gmail or more enterprised focused packages like Salesforce.com is a massively transformative application delivery paradigm, it’s been hamstrung at times by its inability to deal with disconnected or intermittently connected application consumption scenarios. Or, to shelve the consultant speak, the fact that network applications don’t work all that well without the network. It’s what I’ve described in years past as the “Offline Problem.”
Q: How important is that problem, still, with network availability getting better and more pervasive every day?
A: Perspectives vary. when discussing this problem in the past, Alex once joked that we’d solve the offline problem just in time for it to be made obsolete by ubiquitous connectivity. And Rails’ David Heinemeier Hansson apparently is not a big believer in the importance of offline persistence.
With both wifi and EVDO cards built directly into my laptop, I certainly understand the point of view that sahys offline persistence is a lot less important than it used to be. But that’s a far cry from saying it’s not important. As SaaS applications increasing compete against rich client or Rich Internet Application (RIA) alternatives that offer persistence, it will become a more significant limiting factor to adoption. Further, as ubiquitous as connectivity might eventually become, it’s not ubiquitous now. I should know, as I’m spending the summer in a location where the only broadband access is satellite and my best connectivity option is the barely better than dial-up GPRS. Then, of course, there are the planes, the hotels, the office buildings where there is no connectivity. Or, just as often, the convention centers, hotels, airports and so on that do offer wireless – just not wireless that actually, you know, works.
As a result, my personal opinion is that offline persistence for web applications is both laudable and necessary from a strategic competitive perspective. Just because we can endure the pain of not having offline access to web apps, doesn’t mean that we should endure it. If you disagree, here’s a good acid test for you: would you be comfortable delivering a presentation at a conference, relying solely on an online presentation tool? I certainly would not, but YMMV.
Q: Is that a recent opinion? In other words, have your recent application consumption trends affected that opinon?
A: Not particularly. I am, in fact, spending more and more time in the browser; I’ve gone from using Evolution daily to monthly – if that. But the issue bugged me as far back as September of 04 (which, you might notice, immediately preceded the magical October of ’04), when I was disappointed by the fact that the synchronization of my web reader at the time, Bloglines, was only possible to offline rich clients for the Mac and Windows platforms. As of today, I don’t need to worry about that. Took a couple of years, but better late than never and so on.
Suffice it to say that this is in fact a problem that’s bugged me for a long, long time. If you’re really bored, you can take a gander through some of my older entries related to the subject (earliest first): Turning Dross into Gold: Alchemy and Offline Browser Access, Presentation Tools: Offline, Online and Something in Between, So You Want to be an Office 2.0 Provider?, Zimbra: Derby for Offline Persistence, Grand Desktop Ambitions: The Q&A, Is Google Ring Fencing IBM?, and so on.
Q: Bringing it back to the actual Gears announcement, can we examine that in a little more detail? Starting with the technology?
A: Sure. As the initial announcements didn’t specify much in the way of what the individual pieces were – nor did the FAQs appear to – I was curious. But, as they always do, interested parties soon ferretted those out. Here’s John Herren’s breakdown on the individual components to Google Gears:
Google Gears uses three components:
- LocalServer- Handles caching of URL resources on the local file system.
- Database- Gears uses sqlite databases for storage. You can even find the databases on your file system and browse them with any sqlite compatible tool. I did. It works.
- WorkerPool- A job threading API to perform asynchronous operations so your app stays snappy and doesn’t hang. Check out the Fibonacci demo to see it in action.
Gisting this down, you essentially have a local web server (which one, does anyone know?) that serves cached content out of a SQLite database, with a threading mechanism that ensures that abnormally strenuous tasks – say, downloading and caching several thousand email messages – doesn’t bring your browser down while it waits. It’s pretty straightforward, actually.
Q: Is this the first such instance of this technology?
A: Nope, not at all. We’ve had building blocks for a while. Dojo, as an example, has leveraged the storage capabilities of Flash to deliver offline persistence for some time. In this post, Ted comments on a demo of Derby, or JavaDB in this case, being used as the persistence mechanism for an offline web application back at ApacheCon 2005. In November of last year, for example, the folks from Zimbra demoed a very similar Derby based solution to persisting Zimbra data offline; a solution that they’ve since released and that I’m an occasional user of. Not to be left out, two months ago the folks from Joyent announced Slingshot to the world; a framework for allowing Rails applications to persist data in disconnected settings.
In terms of future offerings, the plan for the 3.0 release of Firefox was actually – as I understand it – to include a very similar SQLite based repository for offline persistence.
Google is very much the follower in this space, rather than the first mover.
Q: What’s different about the Google offering? What differentiates it?
A: Most obviously, it’s from Google. None of the other competing alternatives can compete for reach and breadth.
Technically, it also differs from the Flash or Java based approaches, choosing instead to deploy its own, lightweight cross-platform persistence store in SQLite. Unlike some of the alternatives, it would appear that Google’s spent a lot of time on application performance; each application instance has its own sandbox, its own database, and can spawn its own background threads. As a result, according to Google, the performance impact for many applications should be neglible.
The most important differentiator, however, is its ambitions. I didn’t fully appreciate them until I listened to Berlind’s podcast linked to above, but Google would like for gears to become the de facto standard for offline development, a “single, industry standard” approach for delivering offline Ajax applications. Zimbra’s approach was to solve the problem on its own, while the Joyent folks widened the aperture a bit more targeting Rails applications. Google’s intention is for Gears to become the platform for offline apps, and has apparently designed and definitely licensed it as such.
Q: How do you mean?
A: well, let’s take the technology side first. Upson, in the interview above, was very unambiguous is his desire to have a great many developers use the technology. Start listing around 13:20, and you’ll get the picture, as Upson says:
“Clearly we’re very interested in offline enabling all of the interesting Google applications, however, we really want this to be a developer focused release, and it’s still at the experimental stage and we want to get feedback from the broader community, and we know this is going to evolve and change as we learn. I think we’ve done some clever things here, we’ve probably done some things that aren’t so clever, and so we want to be able to change how this works and evolve it over time, based on the partners that we work with and the web developer community. We wanted to have a real application, but we didn’t want to go beyond the development community at this stage.”
From that, it’s clear that Google has attempted not to deliver the once and future framework, but something that really is a beta (rather than a label, as it seems to be with so many of Google’s other offerings). Something that will draw feedback, and evolve towards real deployment scenarios.
Q: And the licensing? How does that encourage adoption?
A: The Gears technology is permissively licensed under a BSD style license, which is the least restrictive and offers the fewest barriers of entry to potential communities. As we recently put it in an internal report delivered to a RedMonk client:
Platform Licensing:
Of particular interest in this case are the strategies employed by platforms. While the GPL remains the overwhelming license of choice for applications in general, and is the choice of perhaps the most popular open source platform in Linux, platform technologies trend towards permissive style licenses as opposed to reciprocal approaches. The BSD distributions are perhaps the most obvious example, but the licensing for PHP – perhaps the most ubiquitous dynamic language at the current time – is another.
At one time, PHP was dual licensed under the GPL and the PHP license, but dropped the GPL as of PHP version 4 because of the reciprocal restrictions. Python’s license is similarly permissive, as it employs its own custom BSD style style license. Mozilla’s Firefox, additionally, was as previously mentioned trilicensed
specifically to address the limitations imposed by its original reciprocal-style license.
Generally speaking, the preference for permissive licenses by platform technologies is that they impose the least restrictions on users and developers, thus offering significant advantages should ubiquity and adoption be an important goal. These advantages, however, come with a price: permissively licensed technologies can be easily and legally forked, or incorporated into proprietary code, or repurposed. The lack of restrictions is both its biggest strength and biggest weakness.
For a commercial entity, then, permissive licensing is best applied to platforms when the vendors wants to grow the market around the platform, monetizing other parts of the market rather than the core platform. For example, the platform may be “free” but tools to interact with and create “content” in the resulting ecosystem may cost.
The decision to apply the BSD style license, then, can be viewed as an attempt by Google to encourage ubiquitous adoption and consumption.
Q: What are the likely impacts to some of the Gears alternatives?
A: From an application provider perspective, I tend to agree with Berlind, who said:
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.
If you’re Zimbra, and your resources are limited, it would make sense to at least ask the question as to whether or continued investment in a redundant offline infrastructure was justified. It could be, for technical reasons, but it might not be as well.
If you’re a Joyent, the question is more complicated. They’re targeting a far more specific niche than Google Gears, in Rails apps, so the question will come down to whether or not Slingshot can offer enough differentiating features to Rails devs to justify their usage of it. Compromising their argument is the fact that Slingshot is not, as yet, available on as many platforms as Gears. Still, they appear content to play David.
Interestingly, Adobe seems to be partnering quite closely; willingly aligning their SQLite efforts with Google’s. That bodes well for Google’s ultimate aims.
Q: Who will be anti-Google Gears?
A: Well, some of the aforementioned alternatives are probably not blissfully happy right now. And there are a variety of players that could ultimately be threatened by the technology. But the least likely to play along, handing Google a de facto standard for offline persistence, would be Microsoft, IMO. I’d be somewhat surprised if we don’t see a similar Windows-like technology emerge. The question, as always, will be their cross-platform story, which Google’s gotten very right here.
Q: How about Mozilla?
A: I was interested to see how they’d react, given that similar ambitions were on their roadmap for 3.0. But they’re apparently partnering with Google on this endeavor, and I actually wonder – pure speculation on my part – whether or not Google’s de facto standard could ultimately replace some of the planned work within 3.0. Either way, Mozilla appears to be on board.
Q: Is Google Gears likely to lead to an explosion of offline applications?
A: Explosion’s probably a little overambitious. One of the things that’s clear as you begin to parse offline application scenarios – and as Upson discusses – is that no two are the same. An offline email client is not the same as an offline feed reader is not the same as an offline CRM system and so on. The application calls, the application storage demands, the application performance implications, even the very utility of offline data access – vary widely. What I expect to see, at least initially, is experimentation. Trials to determine what data needs to be cached, what doesn’t, and so on.
My colleague is of the belief that Web 3.0 will be about synchronization, and he’s taken to calling Web 3.0 the Synchronized Web. Whether you agree with that or not, or like *.0 designation system, there can be no debate that in increasingly online/offline use cases, synchronization – a difficult task at the best of times – will be one of the most significant challenges to tackle.
Q: Couple of questions coming in from #redmonk – was this a 20% project or is it being developed for a specific product?
A: Good question – don’t know the answer. It sounds like the latter, but perhaps one of the Google folks can check in and tell us.
Q: Another set of questions from the #redmonk channel, more technical – “Is WorkerPool positioned against Microsoft’s BITs service for asynchronous IO? Is IO from WorkerPool using the browser connections or its own? If WorkerPool does not have DOM access, does that mean that the JavaScript is being executed in the browser’s JS interpreter or is Gears providing its own? Will other non-browser applications be able to read/write to the local store thus enhancing the user experience?”
A: Don’t have the answers to most of those, but let’s see what we can parse. As for BITs, I suspect that WorkerPool is like it, but that they won’t compete with each other because of a.) scope and b.) the fact that one’s cross-platform and one’s not. As for IO, I don’t know. I’d guess that WorkerPool is using it’s own connections because of the aforementioned issues around multi-threading, but that’s all it would be, a guess. On the interpreter question, I’m fairly sure Gears is using the browser’s because I haven’t heard anything about it incorporating a second, and that would seem to be unnecessarily redundant. Lastly, on the topic of whether non-browser applications can read/write to the local store, I know they can read the DB’s – John Herren’s said as much above. And Adobe and Google appear to be coordinating their efforts on that front to some degree. Whether or not applications can access the pieces more deeply, however, is a question I don’t know the answer to. But would like to, because it has implications for RIA and rich client strategies that could transcend the browser.
Q: Last question from #redmonk: why Gears?
A: Excellent question. I’ll leave it to Google to answer that one officially, just noting that the Gears Firefox Add-on’s caption is “These are the gears that power the tubes!”
Q: Any last thoughts or conclusions?
A: Just that, like the Joyent guys, I think that offline, persisted information is a legitimate game changer. This is the biggest piece of news I’ve heard in a long while.
Update: Had some versioning issues, so had to re-merge some content. Sections originally missing were the enabled applications, and a different version of the “what differentiates Gears”. Apologies.
