Linux 版 (精华区)

发信人: pangwa (everything will go end?), 信区: Linux
标  题: (Eric Raymond)大教堂和市集(7)
发信站: 哈工大紫丁香 (Mon Jan 24 14:19:08 2005), 转信

七. Fetchmail成长起来

　　现在我有了一个简洁和富有创意的设计，工作得很好的代码，因为我每天都
用它，和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能对少数其
他人有用的工作中，我写了一个所有有一个Unix邮箱和SLIP／PPP邮件连接的人都
真正需要的程序。

　　通过SMTP转发功能，它成为一个潜在的“目录杀手”，远远领先于它的竞争
者，这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。

　　我知道你不可以真得瞄准或计划出这样的结果，你只能努力去设计这些强大
的思想，以后这些结果就好象是不可避免的、自然的、注定了的，得到这种思想
的唯一办法是获取许多思想，或者用工程化的思考其他人的好主意而超过原来想
到它的人的设想。

　　Andrew Tanenbanm原来设想建造一个适合386的简单的Unix用做教学，Linus 
Torvalels把Andrew的可能想到的Minix可以做什么的概念推进了一步，成长为一
个极好的东西，同样的(虽然规模较小)，我接受了Card Harris和Harry 
Hochheiser的想法，把它们变得更强大，我们都不是人们所浪漫幻想的天才的创
始人，但是大多数科学和工程和软件开发不是被天才的创始人完成的，这和流传
的神话恰恰相反。

    结果总是执着的原因——实际上，它是每个黑客为之生存的成功!而且它们意
味着我必须把自己的标准定高一点，为了把fetchmail变得和我所能设想的那样
好，我必须不仅为我自己的需要写代码，而且也要包括对在我生活围主页外的人
们的需求的支持，而且同时也要保证程序的简单和健壮。

　　在实现它之后我首先写的最重要的特征是支持多投——从集中一组用户的邮
件的邮箱中取出邮件，然后把它路由到每个人手中。

　　我之所以加上多投功能部分是因为有些用户一直在闹着要它，更是因为我想
它可以从单投的代码中揭露出错误来，让我完全一般地处理寻址，而且这被证明
了。正确解释RFC822花了我相当长的时间，不仅因为它的每个单独部分都很难，
而且因为它有一大堆相互依赖的苛刻的细节。

　　但是多投寻址也成为一个极好的设计决策，由此我知道：

  14. 任何工具都应该能以预想的方式使用，但是一个伟大的工具提供你没料到
的功能。

　　Fetchmant多投功能的一个没有料到的用途是在SLIP／PPP的客户端提供邮件
列表、别名扩展。这意味着一个使用个人机器的人不必持续访问ISP的别名文件就
能通过一个ISP帐户管理一个邮件列表。我的beta测试员提出的另一个重要的改变
是支持8位MIME操作，这很容易做，因为我已经仔细的保证了8位代码的清晰，不
仅因为我预见到了这个特性的需求，而且因为我忠实于另一准则：

　15. 当写任何种类的网关型程序时，多费点力，尽量少干扰数据流，永远不要
抛弃信息，除非接收方强迫这么作!

　　如果我不遵从这个准则，那么8位MIME支持将会变得困难和笨拙，现在我所需
要做的，是只读一下RFC 1652，在产生信头的逻辑加上一点而已。

　　一些欧洲用户要求我加上一个选项来限制每次会话取得消息数(这样他们就可
以从昂贵的电话网中控制花费了)，我很长一段时间拒绝这样做，而且我仍然对它
不很高兴，但是如果你是为了世界而写代码，你必须听取顾客的意见——这并不
随他们不付给你钱而改变。

--
 飞扬的青春
            自由的享受
                      ----欢迎光临Linux版


※ 修改:·pangwa 于 Jan 24 14:22:39 修改本文·[FROM: 210.46.79.57]
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 210.46.79.57]