iframeを持つframeタグにbackとforwardのボタンを付けてみた。
普通に紹介されている方法は

frames[name].history.back();

だけどもWSJSの場合は無名のiframeなので

iframe.contentWindow.history.back();

とする必要が有った。
ま、大した話じゃ無いけど覚書。


Subject: Javaでのキャッシュ制御
Content-type: lovelog/text
Tags: java
Date: 2009/11/09
Public: yes

内部APIを決定するのにTODOにしてあったキャッシュ回りをやらなきゃいけない。
Javaはそもそもオブジェクトのサイズが分からないとかキャッシュ制御が難しい。
キャッシュにかかわるメモリの全体サイズが分からなかればキャッシュを破棄するタイミグすら掴めない。
今回はきちっとしたサイズを得るのは諦めてバッファ部分のみのサイズで処理するつもり。

せっかくなので自前のGDSFアルゴリズムでも作ってみる。
基本的なキャッシュ制御のパラメータは

- キャッシュヒット数
- キャッシュを保持するコスト(サイズ)
- リロードのコスト

ぐらいだけどHTTPの場合は 304応答があるのでチョットややこしい。
とりあえず方針としては

- 304でもキャッシュヒットとする。
- キャッシュのエントリのみを残しバッファは削除という状態を有りにする。
-- この状態でも304は返せる。
- それでもメモリが足りなければエントリも削除する。
-- よほど大量のコンテンツが無いとエントリの削除は意味が無いはず。

ぐらいかな。
で、大雑把な計算式。

- キャッシュヒット数 = アクセス数 / (現在時刻 - キャッシュ生成時刻);
- 保持コスト = バッファサイズ;
- リロードのコスト = Content-typeに依存;
- 基準スコア = キャッシュヒット数 / バッファサイズ;
- スコア = 基準スコア * リロードのコスト;

キャッシュヒット数は最近 n 時間の、とかもっとよさげだが今回はパス。

スコアでソートはコストが大きいので、スコアが平均値以下のキャッシュを破棄とする。
それを30%の空きができるまで繰り返す。普通なら１回で50%前後になる..のか？

...

この方向で実装してみた。何とかと動いているっぽいがテストとか性能確認とか大変そげ。