ノーツの効能(8) - Google Gears とレプリケーション


少し前の話になりますが、オフラインでも Web 上のアプリケーションを利用可能にする技術「Google Gears」を Google が発表しました。(関連記事/ITメディア)

通常のブラウザでも HTML や画像などの静的コンテンツをローカルに保存してオフラインで閲覧することは可能ですが、Google Gears では JavaScriptAjax を生かした Web コンテンツ (一種のアプリケーション) をオフラインで利用可能にします。IEFirefox 向け拡張機能として提供されるほか、開発社向けにオープンソースとて公開されます。


Web アプリをローカルで動かすってことは、ローカルマシン側にコンテンツのサーバー機能や、データ保持のためのデータベース、データ同期のための仕掛けなどなど必要になってきますが、これ、ロータス ノーツの複製機能 (レプリケーション) に似ています。もちろん、使っているテクノロジーはまるで違うので開発者から見ると別物ですが、利用者レベルではまさにノーツのレプリケーションです。


ノーツも Web も、文書情報を共有するための仕組みとして (あるいはそれに向いた構造を持つものとして) スタートしていますが、レプリケーションGoogle Gear の生い立ちは異なります。前者が持つレプリケーション機能は「当時のすっごい遅いネットワーク環境 (それこそ LAN だって使われ始めたばかりで 10Mbps あるいはそれ以下の世界。ひとたびオフィスを出れば、無線などなくアナログ電話+モデムで 2400bps 程度っていう状況) でも効率よく情報を伝播するため」に考案されたものだし、かたや Google Gears は「地下鉄で移動中にフィードを読みたかったから作った」(Google Gearsプロダクトマネージャーのオスマン・ララキ氏/上記 IT メディアの記事より抜粋) とあり、ネットワーク環境がまるで違う状況で生まれているのです。しかし、この Google Gears がどれだけ受け入れられるかは、ノーツがレプリケーションでやってきたことを振り返ってみると何か見えてくるかもしれないなあ、と思ったので、何点かポイントを絞って以下で見ていきます。


(1) 寿命
ネットが当たり前になったとはいえ、いつ・どこにいてもネットにつながる環境を手に入れている人はまだ少数でしょう。これは、PC が無線 LAN やデータ通信に対応しているかどうかだけでなく、つながる環境がどれだけ広がっているか、その環境を利用するために必要なプロバイダーとの契約などの費用が誰でも使えるレベルにある (もしくは公共料金のようにある意味当然のもの受け入れられる環境にある) かどうかといったら、まだまだです。Google Gears の寿命は、これらが解決するまで、と単純に考えることもできそうですが、結構上記の課題が完全になくなるまでにはあと数年はかかるのではないかと思っています。そういう意味で、まだまだ、レプリケーションのニーズはある、と思っています。


(2) どこまで載せる?
Google Gears は、そのプラットフォーム部分はブラウザの拡張機能としてローカルマシンに組み込むのだと思いますが、Web 上で提供されるアプリケーションそのものはこの限りではありません、理論的には。Web 環境をローカルで再現することが Google Gears の仕事でしょうから、Web 上のアプリも利用者がインストールやメンテを意識することはないのだと想像します。ですがこれ、ひとつ間違えるととんでもなく巨大で複雑なアプリをローカルへ複製してしまう可能性もあるわけで、そのあたりは Google Gears の中でなにがしかのロジックを埋めこんで、完全にローカルへ持っていけるものと、オンラインでないと利用できない部分を残し上手にバランスとっていく、っていう実装がよいのではないかと思います。(そのくらい当然考えているよね)


(3) セキュリティー
これ、どうなっているのかしら? コンテンツの暗号化もそうだし、ローカルで実行されるものの信頼性確保なども重要です。ノーツの場合は、まずブラウザに相当するノーツ クライアントそのものがセキュリティーへの配慮が随所にされているし、ローカルに保管するデータの暗号化も備えています。


(4) シームレス
これが一番大事かな。ノーツはこれが完全にはできていない。オンライン/オフラインを利用者がまったく意識しないのが理想。通常はオンライン、ネットが見つからないときだけオフラインモード、というのが基本形。この切り替えを利用者が意識しないのが望ましい。*1 データに関して雑に言うと、コンテンツは「あちら側」(ネット上) と「こちら側」(ローカル保管) で上手に使い分ける --つまり、関連するぜーんぶのデータを持ってこれるわけもないので、必要最小限のデータを手元においてあとは基本的にネット上っていう形-- っていうのが普通考えることだと思いますが、その「必要最小限」の範囲ってどこまでだ?というのが微妙なところ。ITメディアの別な関連記事では、『ほとんどの開発者の場合、クライアントサイドのストレージにキャッシュしておくのは、エンドユーザーにとって意味や関心のある可能性が高いデータだけにするのではないかと思います』との開発者のコメントを記載していますが、果たしてそうか。ノーツのような情報共有基盤を活用している利用者であれば、「意味や関心のある可能性が高いデータ」がメールボックスに入っている割合は少ない(つまり、それらのデータは特定のデータベースに放り込まれているから、そもそもメールで大事な情報そのものが流れることは少ないはず)ですが、たとえばいまのわたしの会社のようにメールと共有フォルダ程度しかインフラがないところでは、メールの中身にかなり重要なものが直接入ってきます。これはこれでぐったりするほど非効率な仕事環境なのですが、そういった企業ではメールの中身って結構大事なものがいっぱい詰まっているはずで、結局過去のメールは全部手元に置きたいっていう要望が多く出てくるのではないかしら。


いずれにしても、期待を持って Google Gears を見ていきたいと思います。第二の「Lotus Weblicator」にならないことを祈って。。。(笑)

*1:ちなみに直接は関連しないけど、無線LANと回線によるデータ通信を利用者が意識することなく切り替わる仕組みってあるのかしら。どちらか状態がいいほうに自動的につながって、切り替えがシームレスである状態。技術的な面、あるいはそれ以外の要因で困難な部分があるのでしょうか?