Jun 1, 2007

Google Gears雑感。

Google Gears (BETA)

LocalServer、Database、WorkerPoolという3つの機能をWebブラウザ上で実現するextension。以下はメモ。

LocalServerは、Webコンテンツをブラウザローカルにキャッシュし、オフラインでもアクセス可能にする機能。ブラウザにはもともとコンテンツをローカルディスクやメモリーにキャッシュする機能があるが、このキャッシュはユーザの操作によって簡単にinvalidateできてしまう。これに対して、LocalServerはWebアプリから完全に制御可能なキャッシュを実現しており、ネットワーク接続が失われた状態でもキャッシュ済みのコンテンツであればトランスペアレントにアクセスできるようになる。どうやって実現しているのかちょっと分からないのだが、ブラウザのリクエストを常に横取りしてmanifestファイルにあるURLならキャッシュしたデータを返すようにしているのかな。だとしたら通常のページのブラウジングが多少重くなるはずなんだけど。

Databaseは一言で言えば、Fat Cookie機能。通常のブラウザに組み込まれているCookieはごくシンプルなpersistent state機能を実現するものだが、Google GearsのDatabase機能はより柔軟で、サイズに対してスケールするpersistent stateを実現したものだと言える(ゆえにセキュリティに関わる問題もcookieと共通する)。具体的には、Google Gearsのpersistent stateはブラウザローカルなリレーショナルデータベース(実装はSQLiteそのもの)として保存され、SQLを使って操作することができる。

WorkerPoolはバックグラウンドタスクを実現する機能。UIのレスポンスを犠牲にすることなく、I/Oやcomputation-intensiveなタスクを実行できる。ブラウザに標準に組み込まれているタイマーリソースだけで実現されたマルチタスクもどきとは雲泥の差がある。データを共有しないところを見ると別プロセスとして実行される(スケジュールはOSが行う)のかな。あるいは、そういう実装を選択せざるを得ないプラットフォームが存在することから演繹された仕様なのかな。

ローカルキャッシュ、Cookie、タイマーはブラウザに標準に実装されている(仕様が標準化されてもいる)のに対して、Google Gearsはそうではないが、「オープン」である。動作環境も多いし、誰でもこのextensionの機能を使ったアプリケーションを書ける。おそらくはGoogleは自社のWebアプリケーションに組み込むことで動作環境としてのde factoを狙う一方で、もう少し真っ当に標準化を行ってde jureとしてもブラウザへの組み込みを正当化するという両面作戦を採るのではないか。

一方で、私はこのextensionの仕様はまだまだ発展途上なのではないかと思っている。例えば、Database機能ではstateの保存にSQLiteを使っていて問い合わせインタフェースがSQLiteの実装に依存している点などは、Google Gearsの実装がmatureでないことを物語っている典型的な証左ではないだろうか。実装がガラス張りなので分かりやすいとも言えるが、バックエンドの実装を別のものに置き換えた瞬間にそれを利用するコードの書き換えが必要になるのでは、ソフトウェアの構築手法として美しくない。

2007-06-06追記:
そうそう。一番肝心なことを書くのを忘れていた。Google Gearsで重要なのは、minimum constructでアプリケーションプロキシーを実現している点。Vistaとか言っている場合じゃないよ。真面目にブラウザだけで任意のオンライン+デスクトップアプリケーションが動かせるようになるよ。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com