Hiroyuki Ikezoe
poinc****@ikezo*****
2003年 11月 2日 (日) 02:31:48 JST
zoeです。 子細かつ丁寧な説明をしていただいて感服しきりです。 ただそれでもやっぱり良く分かった(と思い込める)部分と、もやっとしか分からな い部分とがあったりします。 On Sat, 01 Nov 2003 23:55:06 +0900 Takuro Ashie <ashie****@homa*****> wrote: > KzHTTPはHTTP通信の繁雑さを隠蔽することに徹すれば良いと思います． > ファイルコンテンツを本当に欲しているのは，KzHTTPの利用側です．ですから， > 現状のようにKzHTTPがファイルの中身を保持するのではなく，データを受け取 > るそばからシグナルを発し，利用側がそれをキャッチして新たなデータを自分 > のスプールにため込む，という形が良いと思います． > > ただ，データを受け取る度に毎回シグナルを発するのは性能低下を招く恐れも > あるので，ある程度KzHTTP側でキャッシュする必要もあるかもしれませんし， > また利用側でデータを管理するのは繁雑という面もあるでしょう． > > ですから，現状のコードはそのままで， > > void (*io_in) (KzHTTP *http, guchar *buf, gsize len) > > とかなんとかいうシグナルを適当なタイミングで発するコードを付け加えれば > 良い，という事になります．(ただし，KzHTTPが持っているバッファや一時ファ > イルは，あくまでも「キャッシュ」という扱いです)．メモリやディスクにキャッ > シュするか否かは，利用側がKzHTTP要請するようにします．キャッシュを求め > ない場合は，利用側が独自にコンテンツをメモリにキャッシュするなり，ディ > スクに書き出すなりします． なるほど。実はKzDownloader側からファイルの取得情報を得る”タイミング”が分 からなくて困ってました。KzHTTP側からシグナルを発行すれば何も問題ないですね 。 > こうすると，例えば画像のプログレッシブローディング等に応用する事もでき > るでしょう(本当にやるかどうかは分かりませんが)． 将来、自前レンダリングエンジンを搭載したときには使えるかも:p > GObject > | > +--KzIO (ほとんどのインターフェースはここで定義) > | > +--KzFile (ローカルファイル用．名前は適当) > | > +--KzFTP > | > +--KzHTTP (略) > また，KzIOのインスタンス作成は，専用の工場を用意してやります． > > URIを入力 -> KzIOFactory -> 適切なKzIOを作成して返す > > ただし，C言語なのでわざわざKzIOFactoryなんてクラスは作る必要はなくて， > だたの関数で良いと思います． > > これによって利用側は通信まわりの繁雑さからほぼ解放されるわけですが，上 この辺ははっきりくっきり理解できました。実際コードを書く段階で悩むことがで てくるかと思いますが。 > GtkObject > | > +-- KzDownloader > | > +-- KzMozDownloader > | > +-- KzExternalDownloader(wget等) > > なぜKzMozDownloaderなんてのが必要かと言うと，Mozillaはファイルダイアロ > グをオープンした時には既にキャッシュを始めていますし(止めりゃいいんで > すが)，広く使われている分，我々が作るものよりも(当面は)バグが少ない可 > 能性も高いでしょう．作るのも難しくはないと思うので，用意しておいて損は > ありません．インターフェースを統一する事で，利用側からは同じ物として見 > えるので，特別な処理も必要ありません． これまったく知りませんでした。こういうのって切り離せないんでしょうか。 まあ、今の段階ではしょうがないですが、レンダリングエンジンを複数使えるよう になったときにそれぞれのエンジンがこういう部分を持ってると無駄な気がします 。GtkHTMLを見てみたらば、2も3もgnome-vfs使って通信してました。(3はlibsoupと かいうのも使ってる) 実際にはレンダリングエンジンがそこまで面倒見てくれてるから簡単にブラウザが 作れるわけでありがたいといえばありがたいんですが、あるところまで来るとあり がた迷惑になってる感じが。。愚痴りました。すみません。 > KzExternalDownloaderは，個人的に欲しいというが一番の理由ですが，ブラウ > ザとは別プロセスで動作するので，障害に強い，ブラウザを終了できるという > 利点もあります．クラスを作っておけば，outputを監視して進行具合をグラフィ > カルに，統一的に表示する事ができます．コマンド間の差異は， > KzRemoteBookmarkと同じで，パーサの切替えだけで対応できます． ここがちょっと良く分からないところなんですが、wgetなどをforkするということ でしょうか？ > 最後にKzDownloadBoxですが，一点だけまずい点があります． > KzDownloaderのリストをKzDownloadBox自身が管理していますが，これではサ > イドバーや単独のウィンドウで進行状況を表示したいという時に支障がありま > す．これとは別にKzDownloaderGroupとかなんとかいうクラスを用意すると良 > いと思います．アイテムが追加されたときと削除された時にシグナルを発行す > るようにします． 確かにその通りですね。 > 以前私はzoeさんの日記で「MVCのMをちゃんと作れば，Vはどうとでもなる」と > 発言しました．これはVを軽視しているわけではなくて，むしろViewが最も重 > 要な要素であるからこそ，Modelをしっかりと作り込まなければいけない，と > いう事です． だんだん足永さんのおっしゃりたい事が分かって来ました(笑←笑うとこじゃないか も。 さあ次の肉の日へ向けてプレッシャーがかかってまいりました。
