Web-Applikationen bieten gegenüber Desktop-Programmen viele Vorteile: Man braucht sie nicht zu installieren, sie sind plattformunabhängig und man kann von überall auf sie zugreifen. Dank AJAX und viel JavaScript fühlen sie sich sogar fast wie eine Desktop-Applikation an.
Um sie zu verwenden, benötigt man aber zwingend eine Internetverbindung. Sonst bleibt der Bildschirm weiss. Eine Internetverbindung ist trotz ADSL, UMTS-Datenkarte und Co. allerdings nicht immer überall erhältlich oder auf Dauer zu teuer. Wer nun auch beispielsweise in einem Funkloch seinen Online-Kalender oder RSS-Reader verwenden will, braucht wieder ein Desktop-Programm, von dem man mit der Online-Applikation eigentlich wegkommen wollte.
Google Gears wurde von einem Google-Ingenieur entwickelt, der unterwegs Zugriff auf seinen Online-Newsreader haben wollte. Er erdachte dazu eine Art Zwitter aus Web-Applikation und Desktop-Software in Form einer Browser-Erweiterung (für Firefox und Internet Explorer auf Linux, MacOS X und Windows). Diese muss zwar jeder Anwender auf dem Client installieren, dies aber nur einmal für alle Web-Applikationen, die Gears unterstützen.
Nun funktioniert dieser Offline-Modus nicht automatisch – man muss seine Web-Applikation also explizit mit dem Offline-Modus ausstatten. Dazu bringt Gears mehrere Komponenten mit:
- LocalServer: Ein lokaler Webserver, der zur Auslieferung von Bildern und anderen statischen Inhalten verwendet werden kann, wenn der Benutzer offline ist.
- Database: Eine SQLite-Datenbank, die zur Speicherung der Daten im Offline-Modus dient und mit einer Volltextsuche ausgestattet wurde.
- WorkerPool: Erlaubt die Ausführung länger dauernder Prozesse im Hintergrund, also ohne den Browser zu blockieren.
Alle Komponenten lassen sich über JavaScript-APIs ansprechen. Dies bedeutet allerdings, dass
man parallel zur eigentlichen Applikationslogik für den Online-Modus eine separate für den Offline-Modus in JavaScript implementieren muss. Dies sorgt leider für einen hohen Aufwand, da man quasi die ganze Applikation doppeln muss – inklusive API, Datenbank-Abfragen und -Schema. Insofern ist die Ausrüstung einer Web-Applikation mit Gears-Unterstützung nur dann sinnvoll, wenn der Offline-Modus eine häufig benötigte Funktionalität oder die Applikation entsprechend schlank ist. Abhilfe könnten dereinst spezielle JavaScript-Frameworks wie TrimPath Junction liefern, das versucht, Ruby on Rails zu klonen.
Man ist aber nicht dazu gezwungen, nur dynamische Anwendungen offline verfügbar zu machen. Die lokale Serverkomponente LocalServer lässt sich auch alleine verwenden. So kann man beispielsweise HTML-Dokumente, man denke an Online-Dokumentationen oder Wiki-Seiten, offline verfügbar machen, ohne dass man einen allzu hohen Aufwand treiben muss: Mit zwei JavaScript-Dateien und einem Inhaltsverzeichnis in Form eines Dictionary im JSON-Format (JavaScript Object Notation) können Dateien auf dem Desktop des Anwenders abgelegt werden. Dank Versionierung des Inhaltsverzeichnisses werden diese bei jedem Besuch der Datenquelle aktualisiert.
Wer dagegen eine Applikation von Grund auf neu gestaltet, kann sich überlegen, ob es nicht vielleicht sinnvoll ist, auf den Online-Modus gänzlich zu verzichten. So kann man beispielsweise nur offline arbeiten und die Daten lokal speichern und sie bei Bedarf mit einem Online-Server synchronisieren. Da nur Daten gespeichert respektive aktualisiert werden müssen, lässt sich der Online-Teil relativ einfach halten, sodass der Gesamtaufwand sinkt.
Die APIs von Gears sind einfach gehalten und beschränken sich auf das Minimum. Die Datenbank-API bringt beispielsweise gerade einmal Methoden zum Öffnen und Schliessen der Datenbank-Verbindung, zum Ausführen von Abfragen und zur Abfrage der ID des zuletzt eingefügten Datensatzes mit. Auch bei der Verarbeitung der Resultate muss man mit gerade mal sieben Methoden auskommen, die aber für die Arbeit mit der SQLite-Datenbank ausreichen dürften. Ähnliches gilt auch für den lokalen Server und den WorkerPool, was die Einarbeitung einfach macht.
Die Synchronisation zwischen Desktop und Server muss man dafür von Hand realisieren. Zum Einsatz kommt dabei vorzugsweise und kaum überraschend AJAX, wobei man nicht zwingend XML als Datentransport-Format verwenden muss. JSON oder andere Formate funktionieren auch,
sofern man am Ende die Daten
als JavaScript-Variablen herausbekommt. Das AJAX-Framework dazu muss man selber mitbringen, wobei es egal ist, ob man Prototype, jQuery oder ein anderes Framework verwendet.
Die Aktualisierung der lokalen respektive der Remote-Datenbank muss man ebenfalls manuell erledigen, wobei dies insbesondere zur Lösung von möglichen Konflikten praktisch sein kann. Diese können auftreten, wenn seit der Synchronisation die Daten in der Online-Datenbank beispielsweise von einem anderen Anwender verändert wurden und entschieden werden muss, welche Version behalten werden soll.
Da man mit Gears Daten auf den Desktop des Anwenders schreiben und mit ihm interagieren kann (was sonst mit JavaScript nicht geht), wurden auch einige Vorsichtsmassnahmen vorgesehen. So wird der Anwender beim Aufrufen einer Gears-fähigen Applikation explizit gefragt, ob er der Web-Applikation die Nutzung von Gears gestatten möchte. Zudem können nur Daten von jeweils einer
Domain gelesen werden. Ohne
die Möglichkeit, Cross Domain Requests auszuführen, sinkt das Risiko, dass von Angreifern Schadcode nachgeladen werden kann.
Wer Google Gears selber ausprobieren will, kann dies tun. Google Gears (BSD-Lizenz) steht als Betaversion unter gears.google.com zum Download bereit. Ergänzend dazu findet man eine API-Dokumentation, eine Einführung sowie eine Reihe von Anwendungsbeispielen. Ebenfalls bereit stehen schliesslich Werkzeuge zur Inspektion der lokalen Datenbank und des lokalen Servers, die über den Webbrowser bedient werden können.
Aufbau einer Web-Applikation im Offline-Modus
