syuu syuu 多段キャッシュじゃない、多段串だ。 あと、３つじゃなくて２つね。
syuu うーん。これをやるのと、NicoCache_nl版Genkidamaを作るのとどっちが早いか微妙なところだ。
シンプルにするか、多機能にするか、それは方針というか方向性として決めておいた方が いいと思いますが.....
このケースの場合、外部nicocacheは、Genkidamaを串として動作しているんですよね？ であれば、 ・Genkidamaは外部nicocacheと同じキャッシュを参照する。 ・Genkidamaは今までと同じ処理をする。但しテンポラリファイルは別フォルダか nicocacheの他のシリーズとは別の法則で（ファイルを）ネーミングし、処理終了後削除する。 ・Genkidama自身は完成キャッシュを吐き出さない。 の三点（キャッシュ機能の無効化と同じ意味だと思うのですが）でひとまずそれっぽい動作は しそうな気がするのですが....
キャッシュフォルダ（ディレクトリ）の定期ポーリングは、この件に限っては直結し ないような気がします。（nicocacheを経由せず、直接フォルダにファイルを入れた とか、Genkidama起動中にファイルを削除したというケースで必要だと思いますが、 必要であれば、別の案件として検討すべきではないかと思うのですが....）
もし私の勘違いなら申し訳ないのですが、ちょっと頭のすみに引っかかったので。
token syuu syuu シンプルにするか、多機能にするか、それは方針というか方向性として決めておいた方がいいと思いますが.....
出来るだけNicoCache本体へは手を入れない方向で進めてNicoCache側のバージョンアップへ対応しやすいようにしておき、ニコ動仕様変更へ対応しやすいようにしたいです。
そもそもNicoCache_nlではなくNicoCacheがベースになっているのは、nlの更新が進んでおらず既にニコ動の仕様変更で不具合が起きており、一方でNicoCacheは機能が少ないもののきちんと仕様変更へ追随しているように見受けられたからです。
という事で、私としては純粋にメンテナンスコストが一番低い方法を取りたいというスタンスです。
が、多くの人がnlの機能がないと乗り換えられないとおっしゃるならとりあえずnlも使えるようにする方法は考えたほうが良いな、とは思っています。
本当はNicoCacheとDHTを切り離してコードを単純にし、GenkidamaはDHTの方に専念するという2chに書いてあった話が理想なのですが、現状の方式では技術的に難しいです。 （多段串方式を取らざるを得ず、Proxyとして動作させるなら結局NicoCacheのコードを大部分使い続けるか、ほぼ同じものを再実装する事になります。であればNicoCacheは切り離さない方が得策と思われます）
syuu ・Genkidamaは外部nicocacheと同じキャッシュを参照する。・Genkidamaは今までと同じ処理をする。但しテンポラリファイルは別フォルダか nicocacheの他のシリーズとは別の法則で（ファイルを）ネーミングし、処理終了後削除する。・Genkidama自身は完成キャッシュを吐き出さない。の三点（キャッシュ機能の無効化と同じ意味だと思うのですが）でひとまずそれっぽい動作はしそうな気がするのですが....
私はそもそもファイルへの書きこみ機能自体全部削ってしまってストリームの中継だけやらせれば良いかと思ってたんですが、mitiさんの方法の方が実現は容易かもしれません。
キャッシュフォルダ（ディレクトリ）の定期ポーリングは、この件に限っては直結しないような気がします
キャッシュファイルの書きこみをGenkidamaでやらないと考えたので、自力で書き込んでいない以上キャッシュファイルの書き込みが終了していると正確に知る事は理論上出来ないと考えていました。
が、実際にはストリーム中継の終了を以ってキャッシュ終了と看做す事は可能であり、HTTPをパースすればファイルサイズで正しい大きさかチェックする事も可能である事から、キャッシュフォルダ監視までやらずとも良いと考え直しました。
Genkidama
多段キャッシュを使った外部のNicoCacheへの対応を行いたい。
以下の三つで対応可能と思われる：