[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: buggey-w3m.el



>>>>> at 01 Mar 2001 00:09:03 +0900
>>>>> 土 == TSUCHIYA Masatoshi <tsuchiya@pine.kuee.kyoto-u.ac.jp> said,

土> 認証を必要とする場合に w3m が出力する Username: などのプロンプトを、本
土> 文から安全に削除するため Content-Length: の情報が必要になります。です
土> から、Content-Type: ばかりではなく、一般にヘッダ情報はやはり必要です。

これは了解なのですが、今日会社で新版を試してみて気がついた点があります。
Win32のw3mは-dump_sourceの出力をご丁寧にCRLFにして出してくれます。:-(

その結果、HTML sourceの真の大きさ(Content-Length:)とw3mから出力された大
きさに食い違いが生じ、w3m-http-retrieve のなかで尻切りする際に、不本意な
場所で切ろうとしてしまいます。

Content-Length:による尻切り作業がMUSTとなれば、Win32のためにw3mを若干改
造する必要が生じます。ただ、w3mに手を入れるとしても、(たぶん)標準出力に
対してsetmode(O_BINARY)するようにパッチしする程度なので、これくらいの修
正ならばkokbブランチにも受け入れてもらえるかとも思いますが。

...というのが現状報告。


白井> (1) の dump_head は必要ですよね。やっぱり。
白井> (2) と (3) はそれぞれ別の process で同時に動かせるとうれしいかな?
白井> # だけど、回線の容量とかで、どっちが速いか変わっちゃうかな。

土> なるほど、それも1つの手ですね。プログラムのどの部分が律速しているかが
土> 問題ですねぇ。例えば、w3m の起動時間がネックになっているならば、この解
土> で2倍程度に速くなるはずですよね。

ちなみにdump_headに関してはレンダリングも認証もともなわないHTTPアクセス
なので、elispでアクセスしたほうが良いんじゃないかな。少なくともHEADリク
エストを送ってヘッダ情報を取得するだけなら造作も無いでしょうし。

## Redirect とかもあるだろうから、そればかりじゃないでしょうが,
## HTTPアクセスの詳細を知らないので。。。

で、そうくるならば、認証だけがんばってelispで書くなりすれば、
header + source の取得は elisp 上でできて、あとはファイル化して
w3mに食わせて-halfdumpでレンダリングする、ってのは、、、
現実味無いかしら?


土> よく考えて見ると、POST メソッドの form に対応しようする場合には、どう
土> しても HTTP を直接しゃべらなければいけなくなりそうな気がします。w3m
土> -dump_source に URL を指定しても、POST メソッドを直接に指定する方法が
土> なさそうですから。

土> ## なんで GET メソッドだけではないんだろ。余分な処理が必要になると思う
土> ## のだけれど…

elispでしゃべれるようにすれば、この辺りも解決しますよね。

となるとw3の再発明と区別する部分は、レンダリング処理をw3mにやらせる、
というあたりで、どうでしょう。

## 作業量をあまり見積もらずにオキラクに書いてます。


土> 今後の TODO は、以下のバグを早急に潰すことと、
土> ・ヒストリの動作が変
土> ・テキストファイルが見れなくなった

土> この2つのバグは(多分)潰しました。




土> そういうわけで、url という名前の枝を作成してありますので、新版の開発は
土> そちらでお願いします。cd lisp && cvs update -r url とすればその枝に移
土> 動できます。

了解です。


後> えと、修正がかち合った、とかそういうことが発生したわけでないので、
後> 『済みませんでした』の意味が良くわからないのですが(^_^;

土> うーん。本音を言わせてもらいますと、ちょっと変更が乱暴だったかなあ、あ
土> んまり乱暴なことをして興味をなくされてしまったりしたら悲しいなあ、とい
土> う気持ちがあって、それでもっと相談すべきだったかしら、と思ったのです。

あぁ、そういうことですか。
大改造を施していきなり幹にcommitとかしたならば、そういう話も
出てくるでしょうが、ちゃんと別にして作業しているわけですから
そこはまったく問題にはならないでしょうから、気にしないでください。

また、大改造に関しては、開発を続ける上では、たいていは通らねばならない道
だとおもってますので、これも問題ないです。

--- Regards,
 Shun-ichi Goto  <gotoh@taiyo.co.jp>
   R&D Group, TAIYO Corp., Tokyo, JAPAN