X
Business

Google Apps To-Do Item #72: Make OpenOffice.org into a Google Apps' offline client

If there are two primary objections from the thick client camp when it comes to Web-based applications, then those two are lack of features and the so-called off-line problem (what some refer to as the "airplane problem"). If you need access to a Web server to retrieve Web forms (blank documents, spreadsheets, etc.
Written by David Berlind, Inactive

If there are two primary objections from the thick client camp when it comes to Web-based applications, then those two are lack of features and the so-called off-line problem (what some refer to as the "airplane problem"). If you need access to a Web server to retrieve Web forms (blank documents, spreadsheets, etc.) and to save or retrieve your data and the Web server isn't there (a likely scenario on an airplane where people do a lot of work with out a network connection), what next? Today, some forward thinking developers are clearly looking at ways to recreate the user experience users normally see when they're online, even when they're offline. One of the biggest challenges to doing so has to do with portability.

The client sides of Web applications are inherently portable since they almost always need nothing more than a browser -- something that's available for just about every operating system out there (Windows, Mac, Linux, etc.) -- in order for users to use them. But for Web apps to work offline, they must be able to retrieve and/or write code and data from and to some local repository (otherwise known as a persistence mechanism). For example, if there's no network and you want to start a new document (a process that normally results in the retrieval of a blank Web form), where would the browser find that blank Web form? You could point to the local hard drive, but the minute a browser-based application develops a binary dependency on the local operating system for access to its hard drive, the chief Web app sellling proposition of portability is goes out the window (not to mention the security issues that get raised). 

To address that challenge, developers must look for ways to synthesize a persistence mechanism from the existing browser "infrastructure" that's already in place. Fortunately, there are two relatively ubiquitous browser plugs-ins that can support the local persistence of code and data: Flash and Java. But so far, in terms of using either to reliably provide offline support to commercially available Web applications, there have only been proofs of concept (unless there's one that I don't know of) that test the offline metal of Flash or Java. One of those, currently in early beta, is from Zimbra. It involves Java and Apache's Derby (a database that relies on the presence of Java) and I wrote about it earlier this week. For persistence of local data, the "Zimbra Desktop" calls upon a Java API that in turn makes the whatever call must be made to access the local hard drive. In this respect, portability of the entire application is still maintained because the same code that works in Java on Windows works in Java on any other platform. 

But it's still early for this kind of implementation and judging by the feedback I've gotten from ZDNet's readers, there's a large contingent within the technology community that simply isn't ready to sacrifice the full-bodied software that they're used to running from their PC, that has many more features, and that works just fine without an Internet connection (thank you very much).

But there's also a segment of those users that are Web app-curious. They're interested in the potential for Web apps to lower the total cost of computing, to simplify their infrastructure, and to see if they can loosen their dependencies on specific platforms. But they don't want to try it if it means giving up the comfort of what they have now: something that works. For users of Microsoft Office that qualify, there are solutions like gShare that essentially turn Office into an offline client for Google Apps.

But in order to get more of the status quo experimenting with Google Apps, Google will have to take the offline problems into its own hands. It may indeed have something on the order of what Zimbra has done in the works. But even Google Apps itself is in beta. Which means that whatever Zimbra-like approach Google may cook up for itself, it won't be battle ready for quite some time. 

Where necessary, Google hasn't avoided the development of desktop software. It has made investments in desktop search as well as in its GoogleTalk VoIP and instant messaging client. For it to make the investments it needs to make in order to assuage the Web app-curious would not be a major leap and, near as I can tell, OpenOffice.org is a prime candidate to be deeply integrated with Google Apps. The organizations behind both have already demonstrated (or should I say "established") an interest in the OpenDocument Format and Google, judging by its investments in open source programmers that continue to work on the projects from whence they came (eg: Ben Goodger from Mozilla), has already established a precedent for making contributions to open source project that are in the best interests of its future and its customers. 

As such, I'm adding "Make OpenOffice.org into a Google Apps' offline client" to the ever-growing to-do list of things I'd do if I were the product manager of Google Apps.

Incidentally, if you want to see a demo of the Zimbra Destkop client's offline features in action, be sure to catch the presentation being given by Francois Orsini and Zimbra's Kevin Henrikson and JavaOne next week.  

Editorial standards