[#2571] a mailer written in ruby/Tk — aito@...5nazha.yz.yamagata-u.ac.jp (Akinori ITO)

あ伊藤@山形大学です。

19 messages 1997/04/02

[#2592] FAQ — MAEDA Shugo <ender@...>

前田です。

21 messages 1997/04/03
[#2595] Re: FAQ — matz@... (Yukihiro Matsumoto) 1997/04/04

まつもと ゆきひろです.

[#2596] help — Masao Kanemitsu <masao-k@...>

金光です。調子が悪いので、看てやってください。

71 messages 1997/04/04
[#2597] Re: help — matz@... (Yukihiro Matsumoto) 1997/04/04

まつもと ゆきひろです.

[#2598] Re: help — Masao Kanemitsu <masao-k@...> 1997/04/04

In message <199704040609.PAA22926@castanet.caelum.co.jp>

[#2599] Re: help — matz@... (Yukihiro Matsumoto) 1997/04/04

まつもと ゆきひろです.

[#2653] Re: tk trouble — Masao Kanemitsu <masao-k@...> 1997/04/07

tk関係のサンプルが動いてくれなかった件ですが:

[#2670] Re: tk trouble — matz@... (Yukihiro Matsumoto) 1997/04/07

まつもと ゆきひろです

[#2708] Re: tk etc. — Masao Kanemitsu <masao-k@...> 1997/04/09

In message <199704071537.AAA28214@castanet.caelum.co.jp>

[#2709] Re: tk etc. — matz@... (Yukihiro Matsumoto) 1997/04/09

まつもと ゆきひろです.

[#2713] Re: tk etc. — Masao Kanemitsu <masao-k@...> 1997/04/09

In message <199704090735.QAA11322@castanet.caelum.co.jp>

[#2714] Re: tk etc. — matz@... (Yukihiro Matsumoto) 1997/04/09

まつもと ゆきひろです.

[#2717] Re: tk etc. — WATANABE Hirofumi <watanabe@...> 1997/04/09

わたなべです.

[#2720] Re: tk etc. — matz@... (Yukihiro Matsumoto) 1997/04/09

まつもと ゆきひろです.

[#2739] Dynamic linking (Re: tk etc.) — WATANABE Hirofumi <watanabe@...> 1997/04/10

わたなべです.

[#2740] Re: Dynamic linking (Re: tk etc.) — WATANABE Hirofumi <watanabe@...> 1997/04/10

わたなべです.

[#2744] Re: Dynamic linking (Re: tk etc.) — matz@... (Yukihiro Matsumoto) 1997/04/10

まつもと ゆきひろです.

[#2760] Re: Dynamic linking (Re: tk etc.) — WATANABE Hirofumi <watanabe@...> 1997/04/11

わたなべです.

[#2761] Re: Dynamic linking (Re: tk etc.) — matz@... (Yukihiro Matsumoto) 1997/04/11

まつもと ゆきひろです.

[#2762] Re: Dynamic linking (Re: tk etc.) — WATANABE Hirofumi <watanabe@...> 1997/04/11

わたなべです.

[#2763] Re: Dynamic linking (Re: tk etc.) — matz@... (Yukihiro Matsumoto) 1997/04/11

まつもと ゆきひろです.

[#2765] Re: Dynamic linking (Re: tk etc.) — MAEDA Shugo <ender@...> 1997/04/11

前田です。

[ruby-list:2624] Re: WWW library

From: gotoken@... (GOTO Kentaro)
Date: 1997-04-04 20:03:28 UTC
List: ruby-list #2624
数学会にいかなかった後藤です

思いついたことをだらだら書いてしまったので返事下さる場合は
適当にハショって下さい。

'97年04月04日(金) 午後07時頃、原さん:

 > > 代表的なスキームとアプリケーションの規模を考えとくのは
 > ホームページ1枚(とそれに張りついているSRC)を取ってくる urlget.rb
 > と、簡単なミラーコマンド mirror.rb ぐらいをとりあえずの目標にした
 > らどうでしょう。

いいと思います。 news はどうしましょう。 簡単なアプリケーションは
 ~/.newsrc を見て新しく記事が来てないか調べる chknews.rb の
ようなものやあればとってきてファイルに落すようなものなどです。

引用の順番は前後しますが、

 > > もし、python に習うなら URL は細かいことは関知せず、
 > > そういったものは個別にクラスを用意してそいつらに任せると
 > > いうことになります。 やっぱ、こっちがいいのかなぁ。 
 > その方が部分部分を作りやすいですね。

上のようなアプリケーション程度はこなせるようなのものなら
この方針でそれほど大きくなく作れそうですね。

 > http でもユーザー認証とか修正日情報とか、リクエスト前/同時に送
 > るべき情報がありまね。set_option 系のメソッド実行してから、open 
 > するという形式にする手もありますね。

open が何をするかというのも決めないといけません。
今のところ僕の想像(?)では open の返すオブジェクトは http 
なら GET、 ftp なら login 手順の後、ファイル(ディレクトリ)を
RETL(LIST)をした結果のストリームを readlines で得られるような
モノだと思ってますが、どうでしょう。 open の時点でどこまで
操作しますか?GET なり RETL なりまでしちゃいますか?
仮にそうだとして話しを進めると、 待ち方を考える必要があります。
資源(Resourcce)の取得が終るまでどうやって待ちましょうか。
何も受信状況をモニターできないまま待つのは辛そうですが。

話しは飛びますが
オブジェクトに知っていて欲しいことを思いつくままにあげると

1. 接続のための情報(proxyの場所、 username、 passwdなど)
2, URLから決まる取得要求法
3. 接続の状況(接続中、受信中、完了、失敗など)
4. 取得状況(バイト数)
5. 受けとった資源の種類(mimeのようなもの)
6. デフォルトと例外のマナー

くらいがあると思います(多分抜けもある)。 
で、 3. 4. を用意するとどれくらいゴッツクなるかですよね。
http は content-length フィールドが任意なのでめんどそうでも
あります。 これはライブラリの利用者に任せた方がいいのかなぁ。
ひょっとしてモニターするためにはスレッドという奴が
使えるのでしょうか。

5. は全然加工せずにセーブするならいりません。
でもファイルの種類があまり苦労せずに調べられるのは
ここだけですかねぇ。

6. は失敗した時にどうするか。 再試行するのかどうか。
どこで失敗したかによりますが再試行の場合に、 また open と
いうのは何か変な気がします。オブジェクトの一生は
どういうものだと考えるのがいいんでしょうか。 

それとセーブすることが目的なら、 セーブの際に適当なファイル名を
デッチあげる必要もありますよね。 これはクラスメソッドかなぁ。
いやいや、 考えてみれば file というURIスキームもあるので
そのクラスメソッドにするべきか。 
どちらにせよお手軽URLライブラリを目指しつつあるようなので
ファイル名生成は欲しい機能です。

- -- 

 > やはり DTD から始めてやっと HTML が読めるというのは、凝り過ぎ
 > のような気がする。最初は、簡単な正規表現で捕まえられる程度の
 > 機能でいいのでは?

ま、 そうなんですけど、 DTD から parser の ruby スクリプトを
返すようなものはどれくらい難しいかと思いまして。 
(文書中にコメント以外の宣言はしないとして)
HTML に限らず FAQ の類を linux みたく SGML でまとめとく準備を
しておきたいです。 (実際うちのサイトでもアプリケーションの
インストールメモのような文書を残すのは結構大変)

 > > 個人的にはいろんな引数の善し悪しを調べてくれるものも含んだ
 > >  RFC 番号が名前についたようなライブラリもあると後の開発には
 > > 便利な気もします。 これは欲張りすぎですかねぇ。
 > 問題は誰がその地味な仕事をしてくれるか?ですね。(^_^)

ははは (^^;

 > さしあたって実用になるものを作るか、きちんと定義に従った
 > ものを作るか、それも大きな問題だなあ。
 > ちょっとしたアプリケーションなのに、まず巨大なライブラリ
 > を require してからはじめて動き出す、、、というのもさえな
 > いですしねえ。

そうですねぇ。 
ただ、思惑としては誰かが大規模なアプリケーションか
拡張モジュールが作りたくなるようにいろいろな仕様を
調べた成果を library にまとめとくのも悪くないかと。

- --

あ、そうそう python では、 getHost みたいなのはつぎのように
なってます。
>>> import urlparse
>>> print urlparse.urlparse("http://www.caelum.co.jp/~matz/ruby/")
>>> ('http', 'www.caelum.co.jp', '/~matz/ruby/', '', '', '')
後ろの3つはそれぞれ 「;」「?」「#」 に続くparameter、require、
fragment だそうです。 parameterって何だろ;

-- 後藤

In This Thread