Все решительно изменилось, когда Харри Хочхейзер принес мне набросок исходного текста для почты в SMTP порт клиентской машины. Я сразу понял, что надежная реализация этой особенности сделает другие режимы доставки практически ненужными.

Размышляя об SMTP forwarding, я понял, что popclient может делать очень много вещей. Я разработал транспортного почтового агента (mail transport agent) и агента локальной доставки (local delivery agent). Используя SMTP forwarding, от MDA можно было избавиться совсем и использовать чистый MTA, доставляя почту другим программам примерно так же, как это делает sendmail.

Зачем нужна вся эта путаница с конфигурированием агента почтовой доставки или с установлением на почтовый ящик lock-and-append, если 25-ый порт почти наверняка находится на каждой платформе с поддержкой TCP/IP?

Отсюда можно извлечь несколько уроков. Во-первых идея об SMTP-forwarding была главным вознаграждением, которое я получил за то, что пытался воспроизвести методы Линуса. Пользователи подкинули мне эту идею и все, что мне оставалось сделать – это понять выводы.

11. Иногда использовать идеи пользователей лучше, чем использовать свои идеи.

Интересно, что чем больше вы сознаете, скольким вы обязаны другим людям, тем больше людей считают, что программа написана вами от начала до конца. Это особенно заметно у Линуса. (Когда я читал эту статью на конференции по Perl'у в августе 1997 года, Larry Wall сидел на первом ряду. Как только я произнес вышенаписанные строки, он воскликнул:" Скажи, скажи им, брат!". Все в зале засмеялись, потому что знали, что он тоже работал над созданием Perl'a.) После нескольких недель работы над проектом в таком духе, я начал чувствовать гордость не только перед своими пользователями, но и перед остальными людьми, которые узнавали обо мне. Я снова и снова смотрел на свою почту и удивлялся, неужели, моя жизнь настолько стоящая.

Однако, существуют более фундаментальные уроки, которые не имеют отношения к политике, зато имеют отношение к общему стилю разработки.

12. Часто самые удивительные решения приходят от понимая того, что постановка задачи была неправильной.

Я пытался решить проблему, разрабатывая popclient как комбинированный MTA/MDA cо всевозможными режимами локальной доставки почты. Разработку fetchmail'a требовалось пересмотреть с позиций чистого MTA.

Когда во время разработки программы вы натыкаетесь на препятствие, когда вам приходится серьезно размышлять над следующим шагом, самое время подумать: но не над тем правильный ли вы получили ответ, а над тем правильный ли вы поставили вопрос. Возможно задачу следует переформулировать.

Итак, я переформулировал свою проблему. Очевидно, что нужно было (1)добавить поддержку SMTP forwarding в родовой драйвер,(2) сделать это режимом по умолчанию, (3)выбросить все остальные режимы доставки, особенно возможности доставки в файл и доставки в стандартный выходной поток.

Некоторе время я не решался делать шаг 3, чтобы не подводить пользователей, зависящих от альтернативных методов доставки. Теоретически, чтобы получить тот же самый эффект они могли переключиться на использование.forward файлов или их не sendmail'овские эквиваленты. Практически, такой переход мог вызвать проблемы.

Однако, когда я решился на этот шаг, он принес много пользы. Значительная часть кода драйвера исчезла, конфигурация заметно упростилась,стало не нужно заботиться об MDA, пользовательском mailbox'e, поддержке блокировки файлов операционной системой.

К тому же исчез единственный способ потерять почту. Если у вас определена доставка почты в файл, а диск оказывается переполненным, то почту вы теряете. Это не может случиться при SMTP forwarding, так как SMTP listener не вернет OK, до тех пор пока сообщение не будет доставлено или отложено для более поздней доставки.

Также улучшилась производительность (хотя при единичном запуске вы бы этого не заметили). Другое незначительное улучшение заключалось в том, что справочная система (manual page) стала короче.

Позже, мне пришлось добавить доставку через локальный MDA определенный пользователем, для того чтобы справиться с некоторыми ситуациями связанными с динамическим SLIP'ом. Однако, я нашел для этого более простой способ.

Какой же из этого можно сделать вывод? Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент– Экзюпери – человек, который был летчиком и авиаконструктором, сказал:

13. Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать.

Если ваш код становится одновременно и лучше и проще, вы поступаете правильно. В процессе разработки fetchmail приобрел свое собственное лицо, отличное от старого popclient'a.

Наступило время для смены имени. Новый дизайн больше походил на двойственный sendmail, чем старый popclient. Итак, через два месяца я переименовал его в fetchmail.

В работе над этой программой я использовал много изящных нововведений.

Программа работала хорошо, потому что я использовал ее каждый день, и часто прислушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальная хаккерская задача, которая может быть полезна разве лишь нескольким людям. У меня была программа нужная каждому хаккеру, имеющему UNIX-машину и SLIP/PPP соединение. Благодаря использованию SMPT-forwarding, эта программа могла бы стать «убийцей категории», т. е. программой, которая настолько плотно заполняет свою нишу,что все остальные оказываются просто забытыми.

Я думаю, что нельзя запланировать такой результат заранее. Обычно в разработку вас втягивают настолько мощные идеи, что результаты кажутся естественными и неизбежными. Единственный способ найти такую идею – это постоянно иметь множество всяких своих собственных идей, или обладать талантом заимствовать хорошие идеи у других людей, прежде чем они их осознают.

У Эндрю Таненбаума была идея построить простую UNIX-подобную систему для 386 машины, чтобы использовать ее как обучающий инструмент. Линус Торвальдс использовал идеи Minix, прежде чем Эндрю понял, что из них может получиться.

Этот проект вырос в нечто значительноое. Используя этот же способ (только в гораздо меньшем масштабе), я позаимствовал идеи у Карла Харриса и Гарри Хочхейзера. Вряд ли кого-нибудь из нас можно назвать гением. Однако, обычно научная, инженерная и промышленная разработка совершается не гениями, хаккерами.

Результаты этой работы были и быстрыми, и хорошими. Это был успех, которого хаккер ждет всю жизнь. Теперь, чтобы улучшит fetchmail, я писал код не только для себя, но также добавлял некоторые особенности, необходимые другим людям. Программа же при этом оставалась и простой, и рациональной.

Первое и наиболее важное добавление состояло в поддержке multidrop – особенности, позволяющей выбирать почту из ящиков, предназначенных для группы пользователей, а затем направлять ее получателю.

Я реализовал эту особенность частично потому, что об этом просили пользователи, а частично потому, что это помогло обнаружить ошибки в single-drop. Мне пришлось обобщить проблему адресации. Усилия себя оправдали. Изучение RFC 822 заняло у меня очень много времени, так как пришлось изучить множество несвязанных меджу собой деталей.

Multidrop-адрессация была замечательным решением. Вот что я из нее вынес:

14. Любой инструмент должен быть полезен для тех целей, для которых он разрабатывался. Великий инструмент становится полезным там, где от него ничего подобного не ожидали.

Другим важным изменеием, сделанным по просьбе моих бета-тестеров, стала поддержка 8-битовой операции MIME. Реализовать это было просто, потому что я старался оставить код 8-битным. Не потому что я чувствовал, что придется реализовывать эту особенность, а потому что я старался следовать следующему правилу: