Re: w3m-hist.el

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

>>>>> In [emacs-w3m : No.00383] 
>>>>>	TSUCHIYA Masatoshi <tsuchiya@pine.kuee.kyoto-u.ac.jp> wrote:

山> [...] 今後いろんな関数を作り込んでいきます。

土屋さん> 実装が着々と進んでいるようで、喜ばしい限りです。

とりあえず現時点で思い付く限りの関数を w3m-hist.el に作り込み終
わりました。

;; もちろんこれで終りではないです。経験上は「完成したぜ!」と最初
;; に思ってから、最低でも半年はいじくっていますから。:-p

それから、変な英語かもしれませんがなるべく丁寧に doc-string を書
くようにしたので、興味のある方は読んでみて下さい。

土屋さん> ところで、w3m-url-history のコメントには、history システムで 
土屋さん> content-type や last-modified まで面倒をみるようなことが書か
土屋さん> れていましたが、これは設計の分離が必要なのではないかと思いま
土屋さん> す。

実はあれは思い付きで書いたでたらめな例示だったので、現在はボカし
た書き方に変更してあります。

土屋さん> つまり、

土屋さん> arrived DB => URL によって指定されるページの内容が変更されな
土屋さん>               い限り、変動しない諸々の要素(ファイルサイズ・
土屋さん>               更新日時など)を記録しておく。

土屋さん> history DB => emacs-w3m の起動・停止や、その動作によって変動
土屋さん>               する相対的な要素を記憶しておく。

土屋さん> というように役割分担すればすっきりするだろうと考えているので
土屋さん> すが、どうでしょうか。

そうですね。いずれも非常に大きな DB になる可能性があるものですか
ら、巨大なものを一つ作るよりは分けた方が良いのでしょうね。ぼくは
internal なことはわからないのですが、例えば同一構造の sequence
でも、やはりサイズが大きいほど負荷が重くなるのでしょうか?

ところでぼくは土屋さんとは違う観点から、木構造の `w3m-history'
とは別に一次元の DB である `w3m-history-flat' というものを作って、
それぞれを同期して維持管理するようにしてみました。それぞれの同じ
要素は資源を共有させています。主に木構造を高速で assoc するため
の補助手段のつもりだったのですが、実はこれが土屋さんのおっしゃる
arrived DB としても使えるかもしれません。

ともあれ、今後も当分はじたばたし続けることになると思うので、よろ
しくお願いします。

;; 現時点での最大の問題は、肝心な w3m.el 本体の全容がわかってい
;; ないこと。:-p
-- 
Katsumi Yamaoka <yamaoka@jpl.org>