smtpmail problem

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [emacs-mime-ja : No.01512] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡さん> 非常に無責任な発言だと思います。でも、これをご覧になっている
山岡さん> あなた (中山さんじゃないですよ :) はどうなんですか?

おそらくは山岡さんのお怒りの一番の対象ではないかと思う守岡です。放りっ
ぱなしで、もはや恐くて出て来れない状態ですが、勇気をふりしぼって出て来
てみました。:-)

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

そういう点ではこれまた無責任な発言になることは否めず、この点予めお詫び
しておきます。


山岡さん> >>>>> In [emacs-mime-ja : No.01511] 
山岡さん> >>>>>	Yoichi NAKAYAMA <yoichi ＠ geiin.org> wrote:

山岡さん> > smtpmail の衝突の問題に対してとりあえず FLIM-ELS から 
山岡さん> > smtpmail を消したいと思いますが、そこから使うものと思われ
山岡さん> > る smtp.el, qmtp.elはどうするのがよいでしょうか。

私見を述べれば、smtpmail.el の削除ないしは flim-modules からの削除に賛
成します。原理的には界面が同じなら実装が衝突しても問題ない訳ですが、そ
のために作業する人がいないならば実装の衝突を起こさない方が安全だと思い
ます。

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


山岡さん> 加えて、FLIM の各モジュール、例えば luna.el などに強く依存し
山岡さん> たコードを書くのは、利用者の便を考慮するならば、将来性に不安
山岡さん> を感じます。

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

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

山岡さん> あくまでも「感じ」です。FLIM の各モジュールそれぞれの内容は
山岡さん> すばらしいものですし、ぼくもその恩恵に与ってきた一人です。し
山岡さん> かし、些細な問題であれ、それが起きたときに対処する人がいない
山岡さん> 状態が長く続くようならば (そりゃ自分で何でもできれば、こんな
山岡さん> ことを書く必要は無いのですが)、草々に見切りを付けた方が良い
山岡さん> のではないでしょうか。

個人的感想を述べれば、これまでそんなに大きな問題は生じておらず、このま
までも良いんじゃないかという気もする半面、そういうのは無責任だと思う山
岡さんのお怒りもごもっともとも思います。私が maintainer としての責務を
十分に果たせてないのは事実なので、なってくださる方がいればその方に変わっ
て頂くのが一番だと思いますが、現実問題としてそれが無理なら私としては現
状維持しかないです。

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

(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 の判断に任せると
いうやり方なのだと思いますが、これではやはり問題なのでしょうか？

-- 
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┓
┃『開ける価値の無い      ┃守岡 知彦 (MORIOKA Tomohiko)            ┃
┃　衣裳ダンスの扉は無い』┃                E-mail: <tomo ＠ m17n.org> ┃
┗━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━┛