キャッシュというのはローカルに蓄え込んでしまうと静的なものになってしまいます。サーバー側で最新のアップデートを適用しても，閲覧者がキャッシュを見続けている限りアップデートができません。そこで必要に応じて，ローカルのキャッシュを無視してサーバー側にアクセスさせる必要性がでてきます。というわけで，今回はプログラム側でキャッシュのコントロールが可能なマネージド・リソース・ストアの解説です。
マニフェストの書き方
マネージド・リソース・ストアを利用するには，キャッシュをどのファイルに対してどのように作用させるかを指定する「マニフェスト」と呼ばれる外部ファイルが必要になります。本体プログラムの前に，まずマニフェストの書き方を覚える必要があります。マニフェストはJSON形式で記述します。JSONはJavaScript Object Notationの略称です。CSVやXMLと同じでテキスト形式でデータを記述するデータ記述言語（メタ・データ）です。正式名称にJavaScriptという単語が入っているものの，JavaScriptのプログラムコードそのものではありません。もともとJavaScriptの記法をベースとしているため，JavaScriptとの親和性が高く，Ajaxの世界でもよく利用されるようになってきています。Google GearsはJavaScriptなので，システムとの親和性の高さからJSONが採用されたものと思われます。
Google Gearsの公式ページでマニフェストのサンプルとされているのは次のような構造になっています(リスト1)。
リスト1●マニフェストのサンプル
{
//マニフェストのファイルフォーマット。1で固定。
"betaManifestVersion": 1,
//このマニフェスト固有のバージョン。例として1.2.3を設定
"version": "1.2.3",
//Cookieをリクエストする場合にCookieがないか有効期限が切れていたら
//リダイレクトするURL
//オプショナルなので必須ではありません
"redirectUrl": "login.html",
//URLのキャッシュについてのルール
//複数のファイルについて設定可能
"entries": [
{ "url": "main.html", "src": "main_offline.html" },
{ "url": ".", "redirect": "main.html" },
{ "url": "main.js" }
{ "url": "formHandler.html", "ignoreQuery": true },
]
}
マニフェストはJSON形式なので拡張子は.jsonとして保存します。実際には中身がJSON形式でちゃんと書かれていれば，拡張子は.datでも.manでもかまいませんが，Googleは他のWebサービスでもインターネット上の標準仕様であるRFCを厳格に守る傾向があります。ここは素直に従っておくのがいいでしょう。マニフェストの記述部分はプログラム本体には埋め込まず，必ず別ファイルとしてマニフェストを用意しなくてはなりません。
マニフェストには四つの項目があります。
- "betaManifestVersion": マニフェストの記述形式バージョン
- "version": プログラムのバージョン
- "redirectUrl": リダイレクトURL（任意）
- "entries": キャッシュ対象ファイル
betaManifestVersionは常に1です。これは恒久的にということではなく，現段階では，という認識でいてください。項目名の頭にも“beta”とついています。ベータでなくなったときにどういう記述になるのかはわかりません。また1という値は，おそらく現在のベータ段階の中で，マニフェストのJSON記述スタイルがversion 1であるということを示していると考えられます。JSONフォーマットそのものが拡大されていくことも十分に考えられ，その際にはここが1.1や2という決まりになっていく可能性は非常に高いです。開発者向けの公式サイトは時々確認しておかなくてはなりません。実は本稿を執筆している間だけでも2回ほどサイトに変更が入っています。
versionはプログラマ側で任意に指定できるプログラムのバージョンです。マニフェストそのもののバージョンではなく，このマニフェストがかかわるプログラム／プロジェクトのバージョンととらえてください。プログラムは起動時，つまりHTMLが読み込まれてGoogle GearsのコードであるJavaScriptが実行されていくと，このバージョンを確認します。オンラインの場合はサーバーにあるマニフェストと自身のバージョンを比較して，サーバー側の方が新しい場合に，マニフェストに書かれているソース・ファイルのキャッシュを更新します。つまりマネージド・リソース・ストアの動作のコアであり，極めて重要な意味を持つデータであるというわけです。これについては後ほど実例を含めて確認してみましょう。
redirectUrlは任意項目で，必要がなければ記述を省略できます。Google GearsではCookieを使用することもできます。Cookieがなかったり，Cookieの有効期限が執行している場合に，プログラムとしてどのドキュメントを表示させるかというリダイレクト先を指定します。ファイルはマニフェストのあるディレクトリを起点としてのパス表記，あるいはhttp://×××.××/××.htmlのようにインターネット上のページを指定することもできます。このredirectUrl以外の3項目は必須項目で省略することはできません。
entriesはキャッシュ対象となるファイル名を指定する項目です。マネージド・リソース・ストアの「マネージド」というのは，プログラムの意志によってキャッシュを任意に指定できるという意味で，まさに何をキャッシュするべきかを指定する部分に当たります。ファイル名はマニフェストの位置を起点とした相対パスないしhttp://×××.××/××.htmlのように絶対URLで指定するという点もredirectUrlと同じです。
entriesは値の中にさらに四つの構造を持てます。
- "url" URL
- "src" 指定ページで読み込むソース・ファイル
- "redirect" リダイレクト先
- "ignoreQuery" GET/POSTクエリーを無視するかのフラグ
これらの指定は個別にするのではなく{}内に列記するという形式をとります。言葉で説明するのは難しいので具体的な書式例と意味を見てみましょう。
- [書式例1]
- { "url": "main.html"}
main.htmlをキャッシュします。 - [書式例2]
- { "url": "main.html", "src": "main_src.html" }
main_src.htmlをmain.htmlの名前でキャッシュします - [書式例3]
- { "url": "main.html", "redirect": "main_redirect.html" }
main.htmlを指定あるいはmain.htmlへのリンクでmain_redirect.htmlを開きます。 - [書式例4]
- { "url": "main.html", "ignoreQuery": true }
main.htmlはGET/POSTの引数を無視します。falseにするとデータを受け取ります（デフォルト）。
書式例2はサーバーにあるmain_src.htmlを，main.htmlの名前でローカルにキャッシュしろと言う指示です。ローカルで動作させるには仕組みを変更する必要がある場合などに使用します。
書式例3は2とも似ていなくもないんですが，ブラウザでmain.htmlへの移動が発生した場合に，main_redirect.htmlへ強制的にリダイレクトさせるという指示です。ページ移動はJavaScriptのlocation関数などではなく，HTTPサーバー・レスポンスの302（Moved TemporarilyあるいはFound）が使用されます。
ここまでの設定がキャッシュや移動であることに対して，書式例4だけはちょっと特殊です。ignoreQueryはGETやPOSTでフォームなどから渡される値（HTTPクエリー）を無視するかどうかを指定します。trueにするとクエリーは無視されます。falseを指定するとクエリーはドキュメントに渡されるようになりますが，これは特に指定しなくてもデフォルトがfalseであると解釈してください。クエリーを無視しなくてはならない場合のみ，この項目を設定してtrueを指定します。
ある程度Webプログラムの経験があれば，ignoreQueryは重要なポイントかもしれないと言うことに気がつくかもしれません。例えばニュース・サイトではある記事を表示するのにhttp://×××.××/news.html?number=12345といったURLがよく使われます。Google Gearsではこのまま?以降も付けてキャッシュすべきなのか，それとも丸め込んでしまって12345という記事をnews.htmlとしてキャッシュさせるのかの指定ができるんだということです。
マネージド・リソース・ストアによるキャッシュ制御というのが，単純にキャッシュするかしないかだけではないということが段々と見えてきたように思います。
