Fetchmail växer upp

Där satt jag med en nätt och innovativ design. Kod som jag visste fungerade bra eftersom jag använde den var dag, och en svällande betatestarlista. Det uppdagades gradvis för mig att jag inte längre höll på med ett litet trivialt hack som möjligen kunde vara användbart för andra. Jag ansvarade för ett program som varenda hackare med en Unixlåda och en SLIP/PPP uppkoppling verkligen behövde.

Med 'SMTP forwarding feature', drog den ifrån konkurrenterna tillräckligt mycket för att bli en "kategori killer", ett ev de klassiska program som fyller sin nisch så totalt att alternativen inte bara läggs undan utan nära nog glöms bort.

Jag tror inte att man kan planera för ett sådant resultat. Man får dras in i det av idéer som är så klara att det efteråt framstår som att de är oundvikliga, naturliga och förutbestämda. Det enda sättet att söka efter sådana idéer är att ha många idéer - eller att ha förmågan att bedöma andras goda idéer och att ta dem längre än vad upphovsmannen trodde var möjligt.

Andy Tanenbaum fick den originella idén att bygga ett enkelt UNIX för IBM PC, för att använda som ett undervisningshjälpmedel (Han kallade det för Minix). Linus Torvalds förde konceptet längre än vad Andy troligen trodde att det skulle komma - och det växte ut till någonting fantastiskt. På liknande sätt, fast i mindre skala, tog jag idéer från Carl Harris och Harry Hochheiser och pressade dem framåt. Ingen av oss var 'originella' på det romantiska sätt som folk betraktar genier. Men vetenskap, teknik och programutveckling görs inte av originella genier, hackermytologin till trots.

Men resultaten var i vilket fall rätt häftiga - ja, just den sorts framgång varje hackare lever för! Och det betyder att jag måste sätta mina ribbor ännu högre. För att göra fetchmail så bra som jag  såg att det nu skulle kunna bli, behövde jag skriva inte bara för mina egna behov, utan också inkludera och underhålla inslag som andra utanför min egen krets behövde. Och att göra detta och samtidigt hålla programmet enkelt och robust.

Det första och absolut viktigaste inslag jag skrev efter att ha insett detta var "multidrop support" - dvs förmågan att hämta e-post från e-brevlådor som hade ackumulerat all e-post från en grupp användare, och sedan sända varje e-brev till dess egen adressat.

Jag beslutade att lägga till "multidrop support" delvis därför att en del användare ropade efter det, men mest för att jag tänkte att det skulle skaka fram buggar ur "single-drop" koden genom att tvinga mig att hantera adressering i full generalitet. Och så visade det sig vara. Att få RFC822 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) 'adress parsing' rätt tog mig anmärkningsvärt lång tid. Inte för att någon del är särskilt svår, utan därför att det innehöll en hel hög av suddiga detaljer som var ömsesidigt beroende. Men "multidrop adressing" visade sig vara en "excellent design decision" det också.

Därför att jag vet att

14. Varje verktyg skall vara användbart för sitt ändamål, med de verkligt fina låter sig användas till oanade områden.

Den oväntade användningen av "multi-drop fetchmail" är att köra e-post-listor , och en aliasexpansion gjord på klientsidan av Internet.

Detta betyder att en som kör en persondator med ett ISP-abonnemang kan administrera en e-postlista utan att kontinuerligt ha tillgång till ISPns aliasfiler.

En annan viktig skillnad som betatestarna krävde, var stöd för 8-bitars MIME (Multipurpose Internet Mail Extensions). Detta var ganska lätt att göra eftersom jag hela tiden hade varit noga med att hålla mig till 8 bitar i programkoden. Inte för att jag trott att det skulle finnas efterfrågan på 8-bitars MIME, utan snarare för att hålla mig till en annan regel:

15. När man skriver "gateway software" av något slag, skall man anstränga sig att störa dataströmmen så lite som möjligt - och att aldrig kasta bort information såvida man inte tvingas därtill av mottagaren!

Om jag inte hade följt denna regeln, så hade 8-bitars MIME-stöd varit besvärligt och felbehäftat. Som det nu var, behövde jag bara läsa MIME standarden (RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt)) och lägga till lite trivial "header-generation logic". (Programdelar för att generera brevhuvuden)

Några europeiska användare lurade mig till att lägga in en valmöjlighet att begränsa antalet e-brev per session (så att de kunde ha kontroll på kostnaden för sina dyra telefonförbindelser). Jag stod emot detta länge, och jag är fortfarande inte så glad för det. Men om man skriver för världen så får man lyssna till sina kunder - detta gäller även om de inte betalar med pengar.