smtpmail problem

[Katsumi Yamaoka]

守岡さん、お返事ありがとうございます。

守岡さんのご登場を期待していました。加えるならば K さんや U さん
も。;-)

寺西さん、すみません。Wanderlust のどこかで smtp.el が使われてい
たことが鶏頭の記憶にもあったのですが、やはりそうだったんですね。

>>>>> In [emacs-mime-ja : No.01513] 守岡知彦さん wrote:

> また、smtp.el と qmtp.el は衝突を起こしてないと思うので、削除する必
> 要はないと考えます。

了解しました。

> ただ、残念ながらおそらく当分 FLIM/SEMI のためにかつてのように時間を
> 割くことはできなくなっています。

守岡さんがいつまでも FLIM/SEMI のメインテナンスに振り回される必
要はないと思っていますので、どうかご安心を。むしろ、新しいことを
どんどん開拓していただくことの方が重要です。

何か問題が起きたときに、そのとき作業できる人が対処するのが、この
種の活動の最も理想的な姿だと思いますから、可能ならば木下さんや中
山さんやぼくが、新版のリリースなりを実行してしまえば良かったので
す。しかし、ある一つのまとまったものをばっさり削除することが、他
の選択肢よりほんの少しでも優位であると判断したときに、情熱と英知
を注ぎ込んだ主たる作者を差し置いて行なうことはできません。甘えで
あることはわかっているのですが、ひとことでも反応していただきたかっ
たのでした。ただ、ぼくは日ごろ思っていたことに関して、もう少々言
及してみたい気持ちを持ってもいるのです。

FLIM 版 smtpmail.el の問題自体はたいしたことではありません。よく
出てくる smtp-server の値が未定義で使えないなどの障害に対して、
たぶん安全対策は可能でしょう。真の問題は、ユーザが意図していない
のに Emacs に付属している版ではなくて FLIM 版の smtpmail.el が使
われてしまう可能性が高いことにあります。PC-UNIX の配布版の多くは
FLIM をデフォルトの load-path の上位に含んでいますし、例えば
luna.el や eword-encode.el に依存している emacs-w3m を使うために、
新たに FLIM をインストールした場合でもそうなるでしょう。

> luna.el に関しては、APEL へ移動を強く希望します。また、mcharset.el
> の FLIM への移動も同様です。このようにした新 APEL が release されれ
> ば、それに対応した FLIM 1.15（仮）を出したいと思います。

APEL を整理して lina.el を組み込み、FLIM を README に書かれてい
る「Internet message に関する様々な表現形式や符号化に関する基礎
的な機能を提供するための汎用部品」に特化することに賛成します。

ただ APEL に関しては、一部に根強い誤解と不審を持たれていることと、
XEmacs の標準パッケージに含まれている APEL がおかしなことになっ
ている点がたいへん気掛かりです。

> luna.el の将来性は確かに不透明ですが、luna.el の仕様は十分に枯れてい
> ると思います。特に、CLOS のサブセットとなっている部分を使えば、実装
> としての luna.el に将来性が亡くなったとしてもその code は使えるので
> はないかと思います。

luna.el の有用性は身にしみています。これが Emacs の附属品だった
らなあと思うのはいつものことです。いつか話に出たように、luna.el
と static.el を独立させてしまうのはいかがでしょうか?  そして目標
は Emacs への正式組み込み、その次は FLIM です。

luna.el と static.el は十分に枯れていますが、Emacs に付属してい
る smtpmail.el のように、世界中の有能な人々がよってたかって改良
を積み重ねていくことは、極東のごく小数の人間が限りある時間を割い
て作業するよりも、万人がその恩恵を受けることができる点で、作品そ
のものにとっても幸せな姿だと思います。

また emacs-w3m を例に出しますが、これは APEL と FLIM を利用して
います。FSF Emacs で www 閲覧の限られた機能を使うだけならば無く
ても良いのですが、README をざっと眺めてインストールしてしまう人
が多い気がします。そして現状の APEL と FLIM を必要とすることは、
わかっている人にとっては些細ではあってもユーザが自分で解決できな
い障害に遭遇する可能性が少なくない点で、emacs-w3m は堂々と主流を
標榜することができません。

あるいは XEmacs から APEL を削除してもらうことが、簡単で確実な解
かもしれません。XEmacs の標準パッケージに含まれている APEL を利
用するモジュールは多くはなく、それらのどれもメインテナンスされず
に非常に古いままに捨て置かれているだけです。と、一度発言したこと
があるのですが、どうも現在の XEmacs のメインテナーズには、どこか
の馬の骨の愚痴としか捉えてもらえなかったようです。

すでに変な APEL が広く普及してしまっていて、しかもあらぬ誤解を持
たれている現状で、新たに整理した APEL をリリースするには、かなり
慎重な検証作業が必要でしょう。その重い作業を想像するときに、半ば
捨鉢に出てくる言葉が、

山岡> 草々に見切りを付けた方が良いのではないでしょうか。

なのです。いっそ名前を Advanced-APEL にでも変えましょうか。;-)

> 私として、今後やってみたい（やるかも知れない）割と大型テーマとしては、

> (a) XEmacs CHISE（および Emacs-Unicode）用に Mule-charset 依存コード
>     の書き直し
> (b) MIME-Edit の再実装
> (c) std11.el の luna 化
> (d) std11.el の RFC 2822 化
> (e) MIME-View の method 選択機構の再実装

> があります。私は今の所自分の mail 環境で XEmacs CHISE と FLIM/SEMI
> を使っているので、その都合上、(a) は多分やると思います（そのために、
> mcharset を APEL から FLIM へ移動することを希望します）。(b) 以下が
> やれるかは正直言って判りません（MIME-Edit に対するフラストレーション
> は時々高まっているので、衝動的にやる可能性は０ではないと思いますが）。
> いずれにしても、どれも一般受けしなさそうではあります。(^_^;

> かつての tm のような勢いを求められても少なくとも私には提供できないで
> す。また、個人的感想を述べれば、特に問題なければコードが変わらないの
> は自然ではないかと思います。ただ、問題に対処する人がいないというのは
> 問題と思います。でも、実際に問題になっているのはそれを authorise す
> る手続きなのではないかと思います。そして、これは現状は commiter の判
> 断に任せるというやり方なのだと思いますが、これではやはり問題なのでしょ
> うか？

いいえ。かつて投票制にしたことがありましたが、良く機能した感じは
しませんでした。むしろ、さきほど中山さんが作業して下さったように、
さくさくと改善されていくことは理想の姿だと思います。それにしても
他人の作品を削除するというのは心に重いもので、守岡さんが反応して
下さったことに改めてお礼申し上げます。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>