Следваща страница Предишна страница Съдържание

7. Fetchmail пораства

Така се оказах със спретнат и иновативен дизайн; с код, за който знаех че работи добре, понеже го използвах всекидневно, и с набъбващ списък от бета потребители. Постепенно ми стана ясно, че вече не съм ангажиран с незначителна лична джунджурийка, която евентуално може да бъде полезна другиму. В ръцете си държах програма, от която действително се нуждаеше всеки хакер с Unix система и пощенска връзка през SLIP/PPP.

С възможността за SMTP препращане, програмата дръпна много пред конкуренцията, с изгледи да се превърне в "убиец в категорията си" -- една от онези класически програми, които толкова плътно запълват своята ниша, че алтернативите не само биват изоставяни, но и почти забравяни.

Мисля, че не можете действително да целите или планирате подобен резултат. До него трябва да ви докарат такива силни дизайнерски идеи, че впоследствие резултатите просто изглеждат неизбежни, естествени, дори предопределени. Единственият начин да се домогнете до такива идеи е да разполагате с много идеи. Или да разполагате с инженерна преценка, за да схващате чуждите добри идеи отвъд границите, до които авторите им са предполагали, че е възможно да се отиде.

Анди Таненбаум е имал първоначалната идея да построи една проста нативна Unix система за IBM PC, която да се използва като учебно пособие. Линус Торвалдс е тласнал концепцията за Minix по-напред, отколкото Андрю изобщо е предполагал, че е възможно да отиде. И тя се превърна в нещо удивително. По същият начин (макар и в по-малък мащаб), аз взех някои идеи от Карл Харис и Хари Хокхейзър и ги тласнах силно. Никой от нас не беше "оригинален" в романтичния смисъл, според който хората мислят за гения. Напук на хакерската митология, повечето научни, инженерни и софтуерни разработки не са дело на някой оригинален гений.

Резултатите водеха до едно и също шеметно опиянение -- всъщност, точно това е успехът, заради който живее всеки хакер! И това означаваше, че трябваше да вдигна летвата още по-високо. За да направя fetchmail толкова добър, колкото тогава видях че може да бъде, трябваше да пиша не само за собствените си нужди, но също така да включвам и поддържам възможности извън моята орбита, но необходими за други хора. И да го правя тъй, че да държа програмата проста и ясна.

Първата и изумително важна възможност, която написах след като осъзнах горното, беше поддръжката на множествено пускане -- възможността да се изтегля поща от пощенски кутии, които са насъбрали всичката поща за група потребители, и после всяко съобщение да се маршрутизира до индивидуалните му получатели.

Режих да добавя поддръжката на множествено пускане отчасти защото някои потребители настояваха за нея, но най-вече защото мислех, че това ще изтръска грешките от кода за еднично пускане, принуждавайки ме да работя с адресирането в пълната му всеобщност. Така и стана. Сколасването на правилно граматично анализиране според RFC 822 ми отне забележително много време, и то не защото всяка отделна негова част е трудна, а понеже е заплетена цяла камара от взаимнозависими и мъгляви подробности.

Но адресирането с множествено пускане също се оказа отлично дизайнерско решение. Ето как разбрах това:

14. Всеки инструмент трябва да бъде полезен по очаквания начин, но един истински велик инструмент се употребява по начини, които никога не си очаквал.

Неочакваната употреба на поддържащия множествено пускане fetchmail беше изпълнението на пощенски списъци, където списъкът се пазеше на и псевдонимите се обработваха от клиентската страна на SLIP/PPP връзката. Това означава, че дори някой с личната си машина през ISP акаунт може да управлява пощенски списък, без да разчита на достъп до alias-файловете на Интернет доставчика си.

Друга важна промяна, изисквана от моите бета изпитатели, беше поддръжката на работа с 8-битово MIME. Това беше много лесно за изпълнение, тъй като аз бях внимателен да пазя кода хигиеничен към 8-те бита. Не защото предугаждах изискването на това свойство, а по-скоро заради спазването на едно друго правило:

15. Когато пишеш какъвто и да било шлюзов софтуер, направи си труда колкото се може по-малко да смущаваш потока от данни. И *никога* не изхвърляй информация, освен ако получателят не те принуди да го сториш.

Ако не бях спазил това правило, подръжката на 8-битово MIME щеше да бъде мъчна и пълна с грешки. Но в случая, всичко което трябваше да сторя беше да прочета RFC 1652 и да добавя малко незначителна логика за генериране на заглавия.

Някои европейски потребители ме врънкаха да добавя възможност за избор на броя на съобщенията, обработвани за една сесия (така че да могат да контролират разходите за техните скъпи телефонни мрежи). Дълго време бях непреклонен за това, и то все още не ме радва напълно. Но ако пишете за света, трябва да се вслушвате в своите клиенти -- това не се променя само защото те не ви плащат пари.


Следваща страница Предишна страница Съдържание