[chao 1.14] mmexternal anon-ftp

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> [emacs-mime-ja : No.00575] にて
>>>>> “Yoshiki”= Yoshiki Hayashi <t90553 ＠ m.ecc.u-tokyo.ac.jp> さま曰く:

Yoshiki>>> というのがあります。明示的に EFS が使わない用に指示していな
Yoshiki>>> い限り、ftp で接続に行くのは EFS としては普通の動作だと思い
Yoshiki>>> ます。
Yoshiki> > 
Yoshiki> > ある file 処理 application において、適切な file 名を作るた
Yoshiki> > めに原理的に ftp で接続する必要があれば、その application 
Yoshiki> > を使うことを期待している環境ではそうせざるを得ないのではな
Yoshiki> > いでしょうか？

Yoshiki> 原理的にそうだとしても、常にそうしなければならない理由は無い
Yoshiki> と思いますが。EFS だと、既に /ftp ＠ ftp.example.org:/path
Yoshiki> の形式を扱うことがわかっている訳です。原理的に正しいことをす
Yoshiki> るために、message を表示するだけで ftp server に繋ぎにいくと
Yoshiki> いう user にとっては不便な状況を強いるのは理解できません。
Yoshiki> # 私は software は便利だから使っているだけで、正しさとか定理
Yoshiki> # か何かを証明したりするために使っているわけではありません。

同感です。だから現在の EFS の挙動は直した方が良い気がします。


;; 余談ですが、ある一貫した設計原理にしたがって作っておくと、問題の把
;; 握がしやすくなり、強いてはメンテナンスコストを下げることができると
;; 思います。こうした目的のためには抽象型で考えるのが良いと思います。
;; 例えば、file 名としての意味を考えているならば、file 名型で考えてみ
;; る訳です。また、どの仕様を仮定してどの仕様を実装しようとしているの
;; かを把握する必要があります。で、こうした抽象型に基づく programming
;; は本質的には数理論理学における証明と同じだったりする訳なんですよね。


Yoshiki>>> 別の application が裏に存在するなら考慮しなければならないで
Yoshiki>>> しょうが、mmexternal の下請けの program って何でしょうか? も
Yoshiki>>> し別の backend を作っていて、この動作が嫌であれば override
Yoshiki>>> すれば良いだけですよね?
Yoshiki> > 
Yoshiki> > mmexternal の下請けの program とは ange-ftp, EFS 等の 
Yoshiki> > file-name-handler です。明らかに何らかのこの種の 
Yoshiki> > application が存在することを想定していますよね？
Yoshiki> > 
Yoshiki> > また、例えば、ange-ftp や EFS の代わりに別の同種の 
Yoshiki> > application を使うことにした時に、FLIM でも設定しないといけ
Yoshiki> > ないとしたら嫌でしょう？

Yoshiki> もちろんです。

Yoshiki> > 例えば、mjaa-uri という GNU wget を使い URI を spool に 
Yoshiki> > cache するような ange-ftp の代替 program を使うとします。こ
Yoshiki> > の mjaa-uri は邪悪にもexpand-file-name で spool 上の file 
Yoshiki> > の場所を返す場合があるとします。そうすると、上記の修正は 
Yoshiki> > mjaa-uri の動作を阻害することになります。

Yoshiki> これは concat を使っても同じ問題に遭遇すると思います。concat
Yoshiki> を使おうが expand-file-name を使おうが、結局予期しない動作を
Yoshiki> する application に対しては上記の嫌な個別対応をせざるを得な
Yoshiki> いのでは無いでしょうか。

どの仕様を仮定してどの仕様を実装しようとしているのかが異なります。
file-name-handler-alist をいじるのは file 名に関する実装を提供しようと
している意図だと思われますが、そこで file 名に関する仕様が実装されてい
るという仮定の元で使われるべき expand-file-name を使うのは私には謎です。
例えば、OS 固有の差異を隠蔽しようとするならまだ理解できますが、この場
合そういう意図があるんでしょうか？


Yoshiki> ついでに、expand-file-name と concat のどちらを使うかは私は
Yoshiki> どうでも良いです。私は FLIM 層では対策をしないという方針に反
Yoshiki> 対しているだけです。

私が嫌なのは層間の責任分担の境界が曖昧になることと、data abstraction
的でない何をやっているのかが判らなくなりがちな programming です。
mmexternal において mmexternal と ange-ftp に相当する program の間の界
面をきっちり定義し、個別に実装することには反対しません。つまり、FLIM
層では対策をすること自体には反対しません。ただ、するからにはちゃんとし
てくださいということです。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━