Popclient blir till Fetchmail

Den stora vändpunkten i projektet var när Harry Hochheiser skickade mig sin kod för att befordra e-post till klientmaskinens SMTP-port. Jag förstod nästan med en gång att en tillförlitlig implementering av denna finess skulle göra övriga befordringssätt nära nog överspelade.

I flera veckor hade jag ältat fetchmail i små steg och det kändes som om gränssnittets utformning var hanterbart men kletigt. Klumpig med alltför många betydelselösa möjligheter som hängde med. Möjligheten att dumpa hämtad e-post till en postboxfil eller till standard output grämde mig utan att jag riktigt förstod varför.

(Om du inte bryr dig om teknikaliteter om Internetburen e-post, är det riskfritt att hoppa över följande två stycken)

Det jag insåg när jag tänkte igenom SMTP-postbefordran var att popclient försökte göra alltför många saker. Den hade blivit konstruerad för att bli både en "mail transport agent (MTA)" och en "local delivery agent (MDA)". Med "SMTP forwarding", så kunde den lämna MDA sidan och bli enbart MTA, och lämna över till andra program att göra lokal utdelning såsom sendmail gör.

Så varför krångla till det med att konfigurera en "mail-delivery- agent" eller att sätta upp "lock-and-append" på en brevlåda när port 25 nästan säkert finns på varje plattform med TCP/IP stöd överhuvud taget? Speciellt som detta betyder att emottagen e-post redan garanterat ser ut som normal avsändarinitierad SMTP mail, vilket är vad vi vill ha i vilket fall.

(tillbaka till den högre nivån...)

Även om du inte hängde med i ovanstående tekniska jargong, så finns det flera viktiga läxor här. Först, idén med "SMTP-forwarding" var det största enskilda återbäring jag fick genom att efterlikna Linus metod. En användare gav mig denna fantastiska idé - allt som behövdes var att inse dess följder.

11. Det näst bästa efter att ha goda idéer är är att känna igen goda idéer från användarna. Ibland är det senare bättre.

Intressant nog så märker man att om man är självrannsakande och helt uppriktig om hur mycket man är skyldig andra, så kommer världen i stort ändå att behandla en som om man har gjort alla uppfinningar själv och att man bara visar blygsamhet om sin genialitet. Vi kan alla se hur bra detta fungerade för Linus!

(När jag talade på Perl konferensen i augusti 1997, satt hacker-extraordinaire Larry Wall på främsta raden. När jag kom till slutet i stycket ovan skrek han ut i närmast religiös hänförelse: "tala ut, tala ut, broder!". Hela auditoriet skrattade, de visste att detta hade fungerat även för Perls upphovsman.)

Efter att ha kört projektet några veckor i denna anda, började jag själv få liknande lovprisningar inte bara från användare utan även från andra som hade fått nys om saken. Jag gömde undan en del av denna e-post, så jag kan ta fram den någon gång om jag börjar fundera även om huruvida mitt liv har varit meningsfullt :-).

Men här finns två ännu mer fundamentala, ickepolitiska lärospån som är giltiga i alla sorters designarbeten.

12. Ofta kommer de mest slående och innovativa lösningarna ur insikten om att ens föreställning om problemet har varit felaktig.

Jag hade försökt lösa fel problem genom att hålla på att utveckla popclient som en kombinerad MTA/MDA med alla sorters leveransmoder. Fetchmails design behövde tänkas igenom från grunden som en ren MTA, som en del av den normala SMTP-talande sättet för e-post på Internet.

När man har gått väggen i utvecklingsarbetet - när man märker att man inte kan tänka bortom nästa patch - då är det dags att fråga sig, inte om man har rätt svar, men om man ställer sig rätt fråga. Problemet kanske måste formuleras om.

Ja, jag ställde om mitt problem. Det stod klart att det gällde att (1) hacka in SMTP stöd i den generiska drivrutinen, (2) att göra det till förvald mod, och (3) avslutningsvis slänga ut alla andra moder, i synnerhet skriv-på-fil och skriv-på-standard-output optionerna.

Jag tvekade vad det gällde steg 3 en tid, av rädsla att det skulle ställa till det för användare som länge använt popclient och som var beroende av dessa alternativ. Teoretiskt skulle de omedelbart kunna byta till .forward filer i sina icke-sendmail ekvivalenter för att få samma effekt. I praktiken skulle kanske övergången bli besvärlig.

Men när jag gjorde det så visade sig fördelarna vara kolossala. De knepigaste delarna av driver-koden försvann. Konfigurationen blev betydligt enklare - inget mer harvande med MDA och users mailbox. Inga mer bekymmer om huruvida det underliggande operativsystemet stödde fillåsning.

Det enda sättet att förlora e-post försvann. Om man begärde leverans till fil och disken blev full, så försvann e-posten. Detta kan inte ske med SMTP forwarding eftersom SMTP lyssnaren inte kommer att kvittera OK om inte meddelandet kan levereras eller åtminstone 'spoolas' för senare leverans.

Det gick också snabbare (även om man inte märkte det vid ett enstaka tillfälle). En annan icke obetydlig fördel var att manualen blev mycket enklare.

Senare blev jag tvungen att sätta tillbaka möjligheten att leverera via en användarspecificerad lokal MDA, för att kunna hantera en del obskyra situationer med dynamisk SLIP. Men jag kom på ett betydligt enklare sätt att göra detta.

Sensmoralen? Tveka inte att slänga bort utrangerade funktioner som man kan undvara utan att förlora i effektivitet. Antoine de Saint-Exupéry (som var pilot och flygplanskonstruktör när han inte skrev barnböcker) sade:

13. "Fulländning (i utförande) har man inte uppnått då inget mer finns att lägga till, utan snarare när det inte längre finns något att ta bort."

När ens kod blir såväl bättre som enklare, det är då man vet att den är rätt. Det var i den processen som fetchmail förvärvade en egen identitet som skilde sig från föregångaren popclient.

Tiden för namnbyte var inne. Det nya utförandet såg mer ut som en motsvarighet till sendmail än sin föregångare popclient. Båda är MTAer, men sendmail transporterar bort först och levererar sedan, medan den nya popclienten transporterar hem först och levererar sedan.

Så efter två månaders avvaktan ändrade jag namnet till fetchmail.

Det finns en mer allmän lektion i den här historien om hur SMTP blev till fetchmail. Det är inte bara att avlusning kan göras parallellt; även utvecklingsarbetet och (kanske i förvånande grad) utforskningen av designrummet. När ens utvecklingsstil är snabbt iterativ, så kan utveckling och utvidgning bli till specialfall av avlusning. Att rätta 'utelämningsfel' i programmets ursprungliga funktionalitet eller dess ursprungsidé.

Även på en högre nivå i designarbetet kan det vara värdefullt att ha tänkande från en mängd medutvecklare som går slumpvis igenom designrummet för produkten. Tänk på hur en vattenpöl hittar sin dränering, eller hur myrorna hittar mat: utforskning väsentligen genom diffusion följd av bearbetning förmedlad av en skalbar kommunikationsmekanism. Detta fungerar mycket bra, som mellan Harry Hochheiser och mig. Det kan mycket väl hända att en av ens spejare hittar ett stort och vinstgivande fynd som man själv är för närsynt för att se.