PreviousNextContents


7。Fetchmailの成長

そういうわけで、きれいで革新的なデザインを手に入れ、毎日自分で 使ってるから確実に動くのもわかってるコードもできたし、さらに ベータリストは拡大する一方。だんだんわかってきたのは、自分が やっているのが、ほんの数人にたまたま便利に使えるような、 自分だけのちょっとしたハッキングなんかではなくなってきた、 ということだった。ぼくがいじっているのは、Unixマシンと SLIP/PPPメール接続を持ってるハッカーみんなが本当に 必要としているプログラムだったんだ。

SMTP転送機能のおかげで、このソフトは競合ソフトからぬきんでて、 「カテゴリーキラー」になる可能性まで出てきた。カテゴリーキラー というのは、ニッチをあまりに見事に満たしているので、それ以外の 選択肢は単に放棄されるどころか、ほとんど忘れ去られてしまう ようなソフトのことだ\footnote{訳者註:商業施設では別の意味に なるので注意。店舗の場合は、従来のカテゴリー(家具屋、電気屋、 スーパーなど)にあてはまらない品揃えの店をさす。}。

こういう結果は、狙ってできるものではないし、計画して得られるもの でもないと思う。ものすごく強力なデザイン上のアイデア、あとから 考えると、その結果が当然きわまりなく、自然で、事前に約束され ていたようにさえ思えるようなアイデアによって、そういう結果に 引き込まれなくて はならないんだと思う。そんなアイデアを狙うには、たくさん アイデアを思いつくしかない――または、ほかのひとのいいアイデア をもらって、それをもとの発案者が思ってもみなかったところまで つきつめるというエンジニアリング上の判断を持つという方法か。

Andrew Tanenbaumは、386用に簡単なネイティブのUnixをつくる というアイデアを最初におもいついた。これは教育用ツールとして だった。Linus TorvaldsはMinixのコンセプトを、Andrewが予想 もしなかったくらい遙か遠くにまで拡張した――そしてそれが、 すばらしいものへと成長した。同じように(もっともスケールは 小さいけれど)ぼくはCarl Harrisと Harry Hochheiserのアイデア をもとにして、それをつきつめた。ぼくらのいずれも、みんなが 天才というものを考えるロマンチックな意味では「独創的」 じゃなかった。でも、科学も工学もソフト開発も、ほとんどは 独創的な天才の手になるものではないんだ。ハッカー神話が なんと言おうとも。

でも結果はそれでもなかなか大した代物だった――それどころか、 あらゆるハッカーが死んでもいいと思うような大成功! そして これはつまり、ぼくは自分のねらいをさらに高く設定しなきゃ いけないということを意味する。fetchmailを、いまの自分に 見える可能性くらいにまで優れたものにするためには、自分の ニーズのためだけにコードを書くのではなく、自分の守備範囲 ははずれていても他人が必要としているような機能を加え、 サポートしなくてはならなくなった。そして同時に、プログラムを シンプルで堅牢にしておく必要もあった。

これを認識してから書いた初の、そして圧倒的にいちばん重要な機能は、 マルチドロップのサポートだった。これはつまり、複数ユーザ宛のメール が全部たまっているメールボックスからメールをとってきて、それぞれの メールを個別受信者に選り分ける機能だ。

マルチドロップのサポートを足すことにしたのは、一つには一部の ユーザがしつこくせがんだこともある。でも最大の理由は、アドレッシング を最大限に一般化して対応せざるを得なくなることで、シングルドロップ のコードのバグを全部ひねりつぶせるだろうと思ったからだ。そして それは立派に実証された。RFC822の解析をきちんと実装するには、 えらく長い時間がかかった。これは個別部分が特にむずかしかった からではなく、相互に依存しあった面倒な細部を山ほど片づけなく てはならなかったからだ。

でもマルチドロップアドレッシングは、ふたをあけてみたらこれまた すばらしい設計上の決定だった。なぜそう思ったかというと:

14。ツールはすべて期待通りの役にたたなきゃダメだが、 すごい ツールはまったく予想もしなかったような役にもたって しまう。

――からだ。マルチドロップfetchmailの予想もしない利用法は、 メーリングリストを 運用する際に、リストの管理やaliasの展開を、SLIP/PPP接続の クライアント側でできちゃえることだった。これはつまり、 ISPのアカウント経由で個人マシンを走らせてる人でも、ISPの aliasファイルに絶えずアクセスすることなしにメーリングリストを 運用できるってことだ。

もう一つ、ベータテスタたちが要求してきた重要な変更は、8ビットMIME のサポートだった。これはすごく楽だった。ぼくは自分のコードを 8ビットクリーンにするように心がけてきたからだ。これは、こういう 機能への要望を予想してたからではない。こんな別のルールに従ったまでの ことだった:

15。ゲートウェイソフトを書くときはいかなる場合でも、 データストリームへの干渉は最低限におさえるように必死で努力する こと。そして受け手がわがどうしてもと言わない限り、絶対に 情報を捨てないこと!

この規則を守っていなかったら、8ビットMIMEサポートはむずかしくて バグだらけになっただろう。でも、ぼくは守っていたので、RFC1652 を読んで、ほんのちょっとしたヘッダ生成のロジックを加えるだけで すんだ。

ヨーロッパのユーザの一部は、セッションあたりにとってこられる メッセージ数を制限するオプションをつけるようにしつこくせがんだ (電話代が高いので、それを抑えるためだ)。ぼくは長いことこれ を拒否してきたし、いまでも完全に満足しているとはいいがたい。 でも、世界のために書いているんなら、顧客には耳を傾けなきゃ ――かれらがお金で支払ってるんじゃなくても、これは変わらない。


PreviousNextContents