« 2005年09月07日 | top | 2005年09月16日 »
2005年09月14日
Web2.0 とローカル資源
Webに接続されている各マシンのHDDなど、ローカル資源の活用方法が、
Web 2.0 の重要な一部をなすことになると思う。
Web 2.0は簡単に言えば、生のデータを保持する企業や個人などが、
XMLなどの汎用的なインターフェイスを使ってデータへのアクセスAPIを提供し、
そのAPIをさまざまに組みあわせて最終的な「アプリケーションの生態系」をネット上に構築することである。
たとえば、はてなマップは、Googleが提供する地図APIと、
はてな自身が開発したAPIを組みあわせることで実現されている。
この場合、Google(keyhole)が管理している生データと、はてなが管理している生データが、
WebAPIを通じて出会うことにより、新しいサービスが実現している。
さて、当然だが、Web2.0 でも、秒速30万kmという光の速度は越えられない。
アメリカにある生データにアクセスするためには、プログラムをどんなにがんばっても、
往復で3万キロ = 100ミリ秒が必要だ。 実際にはルーターを何段も介するので、
日本からjavasoftにpingすると、 200ミリ秒近くかかる。
ringo@ringo:/Users/ringo % ping www.javasoft.com
PING www.javasoft.com (192.18.97.48): 56 data bytes
64 bytes from 192.18.97.48: icmp_seq=0 ttl=43 time=197.885 ms
64 bytes from 192.18.97.48: icmp_seq=1 ttl=45 time=185.233 ms
これは光速の30〜60%に相当する。
これ以上、根本的に改善するのはむずかしいだろう。
光速の60%でアメリカからデータを取ってきても、
ローカルメモリやハードディスクにくらべると、圧倒的に遅いのだ。
以下の例でわかるように1000倍以上の開きがある。
ringo@ringo:/Users/ringo % ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.107 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.087 ms
私は、iTunes Music Storeのレスポンス(平均4秒)や、
GoogleMapの地図を取ってくる速度が不満だ。
どちらも、ローカルHDDにデータを大量に保存しておくことで、もっと使いやすくできるはずだ。
たとえば、iTunes Music Storeにおいて、CDジャケットのサムネイルや
試聴用の音声データをローカルに置いておき、それを高速に再生できれば、
より快適にブラウズできるようになり、ユーザー満足も高まり、
音楽の売り上げが伸びることが予想できる。いまは毎回3秒以上待たされるので、
ストレスがたまるために、すぐ使いたくなくなるのだ。
サムネイルや試聴用データのような、最初から無料公開されている情報は、
生データをローカルに置いておくことに対する抵抗は少ないはずだ。
iTunes Music Storeの場合は、100KBの試聴データが100万曲で
100GBになってしまうが、これはすでにふつうのPCに格納できる量である。
サムネイルはもっと小さいし、曲名などのデータは誤差の範囲だろう。
Wikipedia も遅くてどうしようもない(10秒待ちはあたりまえ)から、
そもそもオープンになっているコンテンツはぜんぶローカルにあるべきだ。
GoogleMapに関しては、問題はもっとややこしい。
まず、生データ(50テラバイトとも言われる)をそのまま置くのは、
企業価値が目減りするだろうから無理かもしれない。
インターフェイスをなめらかにするための専用のデータを作っておき、
マウスホイールで高速に変化させたいときはそっちを使う、という風になるのだろうか。
gumonjiとか、SecondLifeのマップデータのような、
マップデータを公開することが企業価値を減らさないアプリの場合は、
最初からぜんぶ送信しておけばよい。
Webブラウザに、「データシンク」という機能をつけて、
サイト単位でデータを同期させ、サイトが提供するjavascriptやフラッシュ等から、
そのデータに自由に簡単にアクセスできるようなAPIがあれば、
webアプリケーションのパワーはさらに加速するだろう。
サブシステムとしてP2Pネットワークに接続されているようにすれば、
データの同期のためにサイトに負荷をかけることも少ないだろう。
現在でもFlashなどからローカルにデータを保存しておいて活用することはできるが、
・デフォルトの容量を大きくする(10GB以上)
・大量のデータを自動的に配信、共有する(P2P)
・DBとして構築し、高速に探したりクエリを発行できるようにする(SQLなど)
・サイトごとの容量調整ができるようにする
という機能を追加することによって、Web2.0 の世界が、より豊かになるに違いない。
このモデルを図にしておく。
いま思いついたが、大容量のiPodのあたらしい利用法として、
iTMSをiPodを利用してブラウズできるようにする、というのがあれば、いいな。
そうすれば、iPod nanoとの共存が可能になってくる。