我把 fetchmail 設計得雅潔而新穎, 程式本身也跑得很好, 因為我天天都在用, 並且開始有一些 beta 版測試者加入, 這情形使我逐漸瞭解, 我已不再是為了 可能讓少數其他人能得到一些便利, 而在進行用處不大的程式棈解, 我已經為 每一位有台 UNIX 機器, 上面跑 SLIP/PPP 來取得電子郵件的玩家們, 寫了一個 真正滿足他們需要的程式.
因為藉 SMTP 埠轉送郵件的這個特色, 潛在使得 fetchmail 足以成為同領域的 殺手級程式, 在同類的典型程式中, 它已經夠資格佔到適當的位置, 使得其他 程式不是被捨棄就是幾乎被遺忘.
我認為沒有人能真的看準或計畫會有這樣的結果, 以有力的設計想法投入這個專案 , 之後的結果似乎是無可避免的, 自然的, 甚至是注定的, 要追求像這樣好的想法 , 唯一的方法就是先擁有許多的想法, 或者以工程上的判斷去取得別人好的想法, 而在此處這個想法的利用已超出原創者的想像.
Andrew Tanenbaum 在 386 上造出了一個簡單的原生 UNIX 系統, 他原先的想法只 是用來作為教學的工具, 但 Linus Torvalds 把這個系統 Minix 的觀念拓展開來, 更進一步, 已經超過 Andrew 當初能夠想像到的發展, 並且成長出一些令人讚嘆 的事物. 我用一樣的方式 (雖然規模較小), 由 Carl Harris 和 Herry Hocheiser 那裡得到一些想法, 然後把它們發揚光大. 在人們的想像中, 歷史上的原創者都是 天才, 而我們兩位都不是, 但是大部份的科學發展和軟體發展工作, 完成者不是 天才原創者, 反而是行家們.
Linux 和 fetchmail 的成果都是一樣令人興奮, 事實上這就是每一位高手追求的 成功, 這些成果指示我應該把標準設得高一點, 把 fetchmail 發展到我所能想像 的理想, 我已不只是為自己的需求而寫, 也為其他人所需要的特色而寫, 並且還要 同時保持程式簡單和強健.
第一個加入的重大特色是 ``多人共用一信箱'' 的支援 -- 這個功能可以抓下累積 在同一個群組信箱中, 而屬於不同使用者的信件, 然後再分送給原來的個別 收信人.
我決定加入 ``多人共用一信箱'' 的支援, 部分是因為有一些使用者們嚷嚷著他們 需要它, 但主要是因為我認為它會迫使我以更通用的法則來處理郵件頭的地址, 並藉此除去 ``一人一信箱'' 功能程式碼中的錯誤, 而我的確也做到了. 為了讓 程式能按 RFC 822 中的規定來檢查信息的語法 , 花了我相當長的時間, 不是 因為規定的個別片段難以理解, 而是因為它包括了成堆相互依賴的瑣碎細節.
[譯注] RFC 822 是 ``Standard for the Format of ARPA Internet Text Messages''.
結果 ``多人共用一信箱'' 的支援的確是一個漂亮的設計, 我是怎麼知道的呢?
[格言 14] 任何的工具以我們所知道的方法來使用都會有用, 但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能.
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
支援 ``多人共用一信箱'' 的 fetchmail 有一種意枓外的使用方法, 就是在以 SLIP/PPP 連線方式連上 ISP 的客戶端執行 ``郵遞討論名單'' (mailing list), 因為它可以配合客戶端的多使用者共用 ISP 上同一信箱 (用別名 -- alias -- 的方法), 讓每個使用者都能在名單上, 這表示我們可以在個人的電腦上, 透過 一個 ISP 的帳號, 來維護一個郵遞討論名單, 而不必持續連著 ISP.
另一個來自我 beta 測試版的使用者的重要需求是接受 8 位元 MIME 郵件格式, 這很容易做到, 因為我過去一直都小心地保持每一個字元碼都是完整的 8 位元, 並非我未卜先知, 而是我遵從另一條法則:
[格言 15] 寫作任何的通信閘軟體時, 要盡可能地不去擾動到通訊的資料流, -- 並且絕對不要丟掉其中任何的資訊, 除非接收方強迫你這麼做.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to!
如果我當初沒有遵從這項原則, 那麼 8 位元 MIME 的支援勢必難以加入並多錯, 所以我需要做的只是研讀 RFC 1652, 然後加入顯然得知的程式碼以產生 MIME 的標頭.
[譯注] RFC 1652 是 ``SMTP Service Extension for 8bit-MIME Transport''
一些歐洲的使用者要我在程式中加入選項, 用來限制每次連線取回郵件的數目 (這樣他們才能控制昂貴的電話線路連線花費), 我拒絕了許久, 甚至到現在, 我 對這個選項的加入仍感到不太愉快, 但假如你是在為全世界寫程式, 那麼 你就應該聽取你客戶們的意見 -- 這個原則不會改變, 因為他們會以金錢之外 的形式給你報酬.