これもしばらく昔に調べたものだけど、どうせなので書いておく。調べた当時、あまりこういう情報は見当たらなかったので。
HTML5というすごく大雑把で、具体的にどの技術を指しているのかよく分からないままに広告とプロパガンダに使われる技術用語、その内に含まれると考えられている技術の中でも特殊な立ち位置と振る舞いを持ったApplication Cacheについては、検討して「ああこれはよく分からん」「ああこれは使えない」と思って利用を諦めてしまった人も多いことと思われる。
僕も真面目にリアルのサービスでモリモリ使っております、という訳ではないのでとても偉そうなことは言えないのだが、前に利用の検討をした時に思ったのは「これは既存のWebサービスに後付けするようなものではなく、初めからその存在を前提としてサービスを作るときに意味のあるものだなぁ」ということだった。
既存のWebサービスに乗っける上で特に厳しいのは、HTML5のapplication cacheがつかえない件 - (ひ)メモ に書いてあるようにapplication cacheのcache manifestを指定したページそのものが、ブラウザのバグでもなんでもなく「仕様として」問答無用でキャッシュされてしまう所にある。サービス固有のユーザアカウントを持ち、ユーザそれぞれに違った「マイページ」あるいはログイン後画面を持つような多くのWebサービスではそれらのページを動的に生成しているのが普通であり、動的に生成したページが一々ローカルにキャッシュされてしまうのでは商売あがったりなんである。
で、その辺含めてもろもろ調べていた時に見つけたのが以下のページ。
Cube Anywhere - Blog: HTML5 offline webapps: a practical example
どうやら"Cube"というサービスでのapplication cacheの使い方を解説したページらしい。ここに主に書いてあるのは、
- Djangoのテンプレートエンジンでcache manifestそのものを動的にレンダリングする
- 細かいことは省くが、ユーザデータの最終更新時刻をcache manifestの中に埋め込む
- それによって、ユーザデータの更新があった際にページがちゃんとリロードされるようにしている
- cache manifestにバージョン番号を含めるアプローチがあるが、あれは糞だ
というような内容。他にも色々、現実にApplication Cacheを使おうとする際に有益であろうことが書いてある。
このページに書かれてあるようなアプローチを取ればどんなWebサービスでもApplication Cacheが有効活用できるZE! みたいなことが言いたい訳ではないし、「とりあえずこうしておけばOK」というような話でもない。ただ、Application Cacheの利用を真面目に検討する人にとっては考えるヒントになると思う。
じゃあの。