nextgenweb

次世代ウェブ:ブラウザーストレージのサポート

次の記事

Youniverseがデートサイト風のものをローンチ

lame_logo次世代ウェブが加速しはじめている。今週、MySpaceがGoogle Gearsを統合し、Yahoo! が新製品BrowserPlusを発表、Googleはブラウザー版の3D Earth製品を公開した。テクノロジーと規格についても、AIRSilverlightJavaFXGearsXULWeb Applications 1.0(DOM5、HTML5等)などが揃い、開発者たちはAJAXの先へと加速され、高性能、多機能でデスクトップと密に連携した新世代のウェブアプリケーションへと導かれていく。

今、開発者とユーザーはともに、以前にはなかったウェブ技術の選択肢を与えられている。さまざまな会社がそれぞれに「次世代ウェブはこれだ」と見せつけるにつれ、「DLL地獄」は「プラグイン地獄」に取って代わられた。しかし、ウェブではこうした選択がユーザーと開発者双方にとって負担となる。ウェブのフォーマットを巡る最初の戦いから10年以上が過ぎた。当時はMicrosoftや、Netscape、Apple、AOLなどが、ブラウザーやスクリプト言語、ウェブサーバー等の形でさまざまな基盤を作った。あの戦いの遺産は今も感じられる。Javascript開発者たちは、ブラウザー無依存のコードを書くためにまるまる ライブラリーに依存し、CSSの開発者は、異なるブラウザーでもサイトが一貫性を保つようにと一連のハックに頼っている。

新しいリッチウェブアプリケーションの技術が未だに発展段階にある今なら、過去の失敗を繰り返すことなく、標準に沿ったアプローチを取れるチャンスがある。ありがたいことにこの10年間で、Microsoftをはじめとする各企業に、以前よりもオープンスタンダードを受け容れる下地が出来てきた。オープンスタンダードの支持が広がることによって、技術はユーザーにとっても開発者にとってもわかりやすいものになるが、たとえば上に挙げたような現在公表されている技術がみんなそうであるかどうかはわからない。

ここTechCrunchの一連の記事を通じて、われわれは次世代ウェブを構成するさまざまな要素に目を向け、その選択肢や現状のサポート、どこまで標準に準拠しているかなどを評価する。MySpaceが最近、同サイトのアプリケーションがGoogle Gearsを使用すると発表したことを踏まえ、第一回ではブラウザーベースのローカルストレージとキャッシュを評価することにする。

ブラウザーベースのローカルストレージ

ウェブアプリケーションが普及してくるにつれ、ウェブベースのアプリケーションをローカルで走らせたいという要求が高まってきた。この種の最初の解は、ブラウザーのプラグインも、別アプリケーションも必要とせず、HTTP中のヘッダーがキャッシュされることを利用してオブジェクトをブラウザーのキャッシュに保存するというものだった。JavascriptライブラリーではDojo が同じ原理を使ってオフラインウエブアプリケーションのサポートを実現したが、ブラウザーに構造化データを保存する手段がないため、アプリケーションの範囲はきわめて限られていた(Dojoは現在、 Gearsをはじめとするさまざまなストレージエンジンの抽象化も行っている ― 情報提供:Dylan)。

2007年5月、GoogleはGoogle Gearsを公開した。ウェブアプリケーションがデータをローカルに保存し、ウェブアプリケーションがローカルで動作できるようにするための、ブラウザープラグインだ。Gears公開時、Google ReaderがGearsをサポートするように改訂され、Gearsのウリとしてオフラインでのアプリケーションアクセスが強調された。あまり知られなかったのは、Gearsがオフラインアクセスだけのものではないことで、主要な機能が3つあった。

  • リソース(HTLMページ、画像等)のキャッシュ
  • データベースの構造化データストレージ
  • 非同期バックグラウンドワーカースレッド

この中で今回われわれが注目するのは、ローカルオブジェクトと構造化データストレージだ。Gearsはこの2つの機能をJavascript API経由で提供しているので、あらゆるウェブアプリケーションからアクセスできる。構造化ストレージは、軽量RDBMSで評判のいいSqliteが提供している。ローカルデータベースと組み合わせることによって、開発者はクエリや挿入を実行して新規データを登録するだけでなく、テーブル間のJOINなど複雑なSQLも実行することができる。Gearsを使ったアプリケーションを複数走らせることができるが、アプリはそれぞれ、ドメインベースのセキュリティーモデル(cookieとAjaxリクエストに似ている)のサンドボックス環境下で実行される。Sqliteは、Firefoxにバージョン2.0から組み込まれているが、APIはアドオンまたはFirefoxのコア部品からしかアクセスできない。Gearsのプラグインは、このギャップを埋め、クライアントスクリプト環境で利用できるようにする。

Gearsが公開される前から、ウェブ・ハイパーテキスト・アプリケーション・ワークグループ(WHATWG)がウェブアプリケーション1.0のドラフト仕様の作業を開始しており、そこにはHTML5の一部として構造化データストレージが含まれていた。同ワークグループの現ドラフト仕様には、ローカルデータストレージのアクセスおよびクエリのためのデータベースオブジェクト定義が含まれている。実装の詳細はベンダーに任されているが、APIは仕様に詳細に書かれている。Firefoxは、WHATWG仕様の同じストレージAPIの一部をブラウザーのV3.0に実装する予定で、現在プレビューリリースが入手可能だ。WHATWGの仕様の主なコンポーネントは以下のとおり。

  • アプリケーションキャッシュ – ローカルのブラウザーキャッシュにオブジェクトを保存(およびチェック)するため
  • navigator.onLine – ブラウザーがオンライン状態かどうかをチェックする(そして、必要に応じてキャッシュとローカルデータストアを使用する)
  • ストレージインターフェースおよびイベント – sessionStorageのDOM属性経由で名前と値のペア保存するために使用する
  • データベース インターフエース – ローカルデータベースへの接続に使用する。SQL(またはそのサブセット。使用するサーバーによる)、バージョニング、コールバック経由のエラーイベントをサポート
  • スレッド化とコールバック – 複数のリクエストを非同期に、ローカルデータストアに送るため

ローカルストレージやキャッシュ、オフラインアクセスなどの実装は比較的容易だ。アプリケーションはまず、その機能がサポートされているかどうかを調べ、次に、バックグラウンドでユーザーデータを同期させることによって、ローカルキャッシュを構成する。アップロードでもダウンロードでもスレッドの実行中、ステータスを調べてユーザーにフィードバックすることができる(プログレスバー等)。ひとたびデータがローカルにやって来れば、開発者はローカルマシン上でデータベースクエリを実行することによって、飛躍的に性能を向上させられる。現在、多くのウェブアプリケーションが、ブラウザーをプレゼンテーションレイヤーとしてのみ使っている。たとえば、表計算アプリケーションなら、=1+1などの基本的な計算であっても、処理のためにサーバーと往復することがある。ローカルデータストアとクライアントサイドコードを利用すれば、開発者は処理とストレージをクライアント負荷分散できるとともに、スムーズなデスクトップライクな体験の提供が可能になる。

サポートの現在と将来

問題は、WHATWG仕様の大部分が、Gearsがリリースされた後に書かれていることで、このためGearsで使用されているデータベースとローカルサーバーは、WHATWG仕様と互換がない、少なくとも現時点では。期待できるのは、GoogleがWHATWG HTML5仕様のストレージ部分を全面的に支持すると表明していることで、これでGearsをインストールしたFirefox 3で動くアプリの開発者は、ネイティブの実装を使うか、Googleの実装を使うかを選ぶことができる。Googleはさらに、追加機能を提供することによって、開発者がHTML5の実装に加えてGearsをターゲットにし続けるインセンティブを与える(デスクトップショートカットなどの機能)。

ローカルデータストレージの他の選択肢、たとえばFlashローカルストレージは、WHATWG仕様と全く互換かない。WebKitの開発者は実にすばやくHTML5仕様のストレージ部分の実装も開始したことを発表した。現在毎日ビルドを入手できる状態なので、近いうちにKonquerorとSafariの両方でサポートされるだろう。Operaも同じような計画を発表しているが、実はHTML5とウェブフォームの実装に関しては他より先を行っている。Yahoo!のBrowserPlusはきのう発表されたばかりで、その中のローカルストレージサポートがWGの決めた仕様と互換性があるかどうかはまだわかっていない。

ローカルストレージは、新しいウェブAPIの主要な新機能であり、開発者はブラウザーに依存しない一貫性のあるサポートが可能になるだけではなく、Google Gears(既に利用可能)やYahoo! BrowserPlus(どう動作するかによるが)という選択肢も手に入れることができる。この議論の中で、ブラウザーのメーカーで1社だけ抜けているところがあるが、それはMicrosoftだ。MicrosoftはIE8の早期プレビューをリリースし、山ほどの新機能を発表したが、その中の多くは、CSSの改良やJavascriptのサポート(標準オブジェクトモデル強化)等、オープンスタンダードに基づいたものだ。大きな問題は、IE8が他のブラウザーベンダーと同じ仕様の一貫性のあるローカルストレージのサポートを行うかどうかだ。IEチームは、IE8がDOMストレージをサポートすると発表しているが、これはローカルストレージ仕様全体のほんの一部でしかない(即ち、上に書いたストレージオブジェクトのみ)。

現在と将来のサポートの概要

  Gears

BrowserPlus

Firefox IE8

Webkit

アプリケーションキャッシュ

近日中

オンライン状態の検出

ローカルサーバー

ストレージ

データベース

スレッド化

SQL

注:BrowserPlusの詳細がわかり次第、表の空所を埋める予定。Gearsは標準に準拠することを約束している。IE8は部分的サポートのみを表明。WebKitのナイトリービルドにはほぼ全機能が含まれる。FlashとSilverlightいずれもローカルストレージの一種を持っているがHTML5の標準APIとは異なる。

ブラウザーのローカルストレージのような新技術が、ここまで支持され、ほぼ単一の仕様が採用されるのはきわめて珍らしいことだ。Microsoftはまだ全面サポートを表明していないが、正しい方向に進んでいることは間違いない。また、Google GearsとFirefox 3のHTML5の実装が、ワーキンググループ仕様に沿っているのも心強い。ブラウザーの新バージョンが広く行き渡るまでにはしばらく時間がかかるだろうが、Google Gearsは現在入手可能であり、どの開発者も同じAPIをターゲットにしているので、今開発者は安心してGearsのストレージAPIをターゲットにしてコードを書くことができる。これは、少し前にはほとんどあり得なかったことだ。

ローカルブラウザーストレージとキャッシュに関して、オープンスタンダードが今の勝者だ。他のソリューションは、消えていくか、同じAPIを実装することになるだろう。

[原文へ]

(翻訳:Nob Takahashi)