Takuro Ashie
ashie****@homa*****
2003年 11月 1日 (土) 23:55:06 JST
足永です．
UI等のアイデアはとりあえず置いておいて，とりあえず設計の部分だけ．
At Wed, 29 Oct 2003 19:21:30 +0900,
Hiroyuki Ikezoe wrote:
> 昨日の夜足永さんの日記を読んで、やっぱりKzHTTPから派生させりゃよかったあと
> 思ったんですが、まだそうなってません。なんでそうなっていないかというと考え
> がまとまらなかったからです(笑。
> KzFTPとかできたときにはどうなるんだろ？…考え中…考え中………わからん…。
> とまあそんあ具合です。
いえ，現状のままで良いと思います．
KzHTTPはHTTP通信の繁雑さを隠蔽することに徹すれば良いと思います．
ファイルコンテンツを本当に欲しているのは，KzHTTPの利用側です．ですから，
現状のようにKzHTTPがファイルの中身を保持するのではなく，データを受け取
るそばからシグナルを発し，利用側がそれをキャッチして新たなデータを自分
のスプールにため込む，という形が良いと思います．
ただ，データを受け取る度に毎回シグナルを発するのは性能低下を招く恐れも
あるので，ある程度KzHTTP側でキャッシュする必要もあるかもしれませんし，
また利用側でデータを管理するのは繁雑という面もあるでしょう．
ですから，現状のコードはそのままで，
void (*io_in) (KzHTTP *http, guchar *buf, gsize len)
とかなんとかいうシグナルを適当なタイミングで発するコードを付け加えれば
良い，という事になります．(ただし，KzHTTPが持っているバッファや一時ファ
イルは，あくまでも「キャッシュ」という扱いです)．メモリやディスクにキャッ
シュするか否かは，利用側がKzHTTP要請するようにします．キャッシュを求め
ない場合は，利用側が独自にコンテンツをメモリにキャッシュするなり，ディ
スクに書き出すなりします．
こうすると，例えば画像のプログレッシブローディング等に応用する事もでき
るでしょう(本当にやるかどうかは分かりませんが)．
また，KzHTTPのような物は，各言語のIOまわりのライブラリとかを見てもらえれ
ば良く分かると思うのですが，以下のように汎化してやると，利用側にとって
使いやすく，拡張性の高いものになります．
GObject
|
+--KzIO (ほとんどのインターフェースはここで定義)
|
+--KzFile (ローカルファイル用．名前は適当)
|
+--KzFTP
|
+--KzHTTP
(普通はKzFTPやKzHTTPの親クラスとしてKzNetとかがあったりするのですが，
我々が欲しいのはせいぜい上記の3つでしょうから，どちらでも構わないと思
います．KzNetの部分は，GNetでほぼ事足りているわけですし．)
上記のようにローカルファイルも抽象化してやると，実はKzBookmarkと
KzRemoteBookmarkなんてのは分割する必要が無いのだ，という事になります．
(そして，現実にKzBookmarkとKzRemoteBookmarkの統合は必要になる可能性が
高いです．なぜならば，例えばXBELをリモートから取得したいとします．しか
し，KzXBELは既にKzBookmarkから派生しています．じゃあ，新たに
KzRemoteXBELを用意するのか...? 違いますよね?)
また，KzIOのインスタンス作成は，専用の工場を用意してやります．
URIを入力 -> KzIOFactory -> 適切なKzIOを作成して返す
ただし，C言語なのでわざわざKzIOFactoryなんてクラスは作る必要はなくて，
だたの関数で良いと思います．
これによって利用側は通信まわりの繁雑さからほぼ解放されるわけですが，上
の図を見てもらえれば分かるように，KzDownloaderがKzHTTPを継承すると大変
な事になります．KzDownloaderはダウンロード後のローカルファイルの管理も
同時行う事になるので，本質的にIOとは別物であると言えます．
次にKzDownloaderですが，これそのものはとりあえず今のままでほぼ問題ない
と思います．が，たぶんKzMozDownloaderなんてのが必要になります．また，
KzExternalDownloaderなんてのがあるともっと嬉しいです．
GtkObject
|
+-- KzDownloader
|
+-- KzMozDownloader
|
+-- KzExternalDownloader(wget等)
なぜKzMozDownloaderなんてのが必要かと言うと，Mozillaはファイルダイアロ
グをオープンした時には既にキャッシュを始めていますし(止めりゃいいんで
すが)，広く使われている分，我々が作るものよりも(当面は)バグが少ない可
能性も高いでしょう．作るのも難しくはないと思うので，用意しておいて損は
ありません．インターフェースを統一する事で，利用側からは同じ物として見
えるので，特別な処理も必要ありません．
KzExternalDownloaderは，個人的に欲しいというが一番の理由ですが，ブラウ
ザとは別プロセスで動作するので，障害に強い，ブラウザを終了できるという
利点もあります．クラスを作っておけば，outputを監視して進行具合をグラフィ
カルに，統一的に表示する事ができます．コマンド間の差異は，
KzRemoteBookmarkと同じで，パーサの切替えだけで対応できます．
最後にKzDownloadBoxですが，一点だけまずい点があります．
KzDownloaderのリストをKzDownloadBox自身が管理していますが，これではサ
イドバーや単独のウィンドウで進行状況を表示したいという時に支障がありま
す．これとは別にKzDownloaderGroupとかなんとかいうクラスを用意すると良
いと思います．アイテムが追加されたときと削除された時にシグナルを発行す
るようにします．
以前私はzoeさんの日記で「MVCのMをちゃんと作れば，Vはどうとでもなる」と
発言しました．これはVを軽視しているわけではなくて，むしろViewが最も重
要な要素であるからこそ，Modelをしっかりと作り込まなければいけない，と
いう事です．
「マイホーム」を建てるとき，「マイホーム」が最も重要な要素であるからこ
そ，「マイホーム」が壊れないように「基礎工事」をしっかりと行わなければ
ならないのと一緒です．