Pour populaire qu'elle soit, l'architecture Ajax (Asynchronous Javascript and XML) ne gère pas nativement le mode déconnecté. Une application Ajax doit impérativement être connectée à un serveur. Cette limite handicape fortement les
utilisateurs mobiles. Pour y remédier, Google a dévoilé Google Gears, une technologie destinée à développer des applications Ajax fonctionnant en mode déconnecté. L'objectif de Google consiste, entre autres, à rendre ses outils bureautiques -
Gmail, Calendar, Docs, Spreadsheet, etc. - disponibles n'importe quand.
Distribué sous licence open source, Google Gears se compose de trois modules : une base de données locale, un cache de ressources qui remplace le serveur HTTP, et un moteur d'exécution de processus asynchrones. L'ensemble est
packagé sous la forme d'une extension pour Firefox 1.5 et Internet Explorer 6.0, et chapeauté par une API de haut niveau. Celle-ci masque, notamment, les problématiques de synchronisation entre les caches locaux et les serveurs. Le cache de
ressources (Localserver) et la base de données (Database) stockent les informations et fichiers provenant du serveur lorsque l'utilisateur est connecté. En mode déconnecté, c'est vers eux que seront reroutés les appels http interceptés.
Les applications web fonctionnent sans serveur HTTP
1. Toute l'application dans un cache
Le cache de ressources (Localserver) remplace le serveur HTTP distant. Il stocke l'ensemble des éléments de l'application - pages HTML, bibliothèques Javascript, images, feuilles de style (CSS), etc. - sur le poste
client. Il intercepte les requêtes HTTP de l'application lorsqu'elle fonctionne en mode déconnecté. C'est également lui qui autorise son démarrage en mode déconnecté.
2. Une base de données locale
La base de données locale (Database) s'appuie sur le moteur SQL open source SQLite. Elle stocke en local les données téléchargées par l'utilisateur lorsque celui-ci est connecté. En mode déconnecté, c'est la base de données locale
qui est utilisée par l'application. Un moteur de synchronisation se charge de réconcilier les données lorsque l'utilisateur se reconnecte.
3. La synchronisation s'effectue toute seule
Bien que Google Gears accepte différents modes de synchronisation, l'éditeur préconise de recourir le plus possible à la base de données locale, de façon à augmenter les performances de l'application. Dans ce schéma, c'est le
client qui est le maître de la synchronisation, laquelle s'effectue en continu, en tâche de fond.
4. Des traitements asynchrones en tâche de fond
Les synchronisations de données nécessitant souvent du temps, Google propose un troisième module. Baptisé Workerpool, celui-ci élimine les blocages du navigateur dus à l'exécution trop longue de scripts. Ce module transforme les
traitements Javascript synchrones en processus asynchrones.