Popclient becomes Fetchmail
POP-asiakasohjelmasta täysiveriseksi Fetchmailiksi
The real turning point in the project was when Harry Hochheiser sent me his scratch code for forwarding mail to the client machine's SMTP port. I realized almost immediately that a reliable implementation of this feature would make all the other mail delivery modes next to obsolete.
Projektin varsinainen käännekohta tuli, kun Harry Hochheiser lähetti minulle luonnoskoodin siitä, miten sähköpostit voidaan välittää asiakaskoneen SMTP-porttiin. Tajusin melkein heti, että jos onnistuisin toteuttamaan tämän ominaisuuden luotettavalla tavalla, muut sähköpostin jakelutavat tulisivat käytännössä tarpeettomiksi.
For many weeks I had been tweaking fetchmail rather incrementally while feeling like the interface design was serviceable but grubby—inelegant and with too many exiguous options hanging out all over. The options to dump fetched mail to a mailbox file or standard output particularly bothered me, but I couldn't figure out why.
Olin kehittänyt Fetchmailia viikkojen ajan pienin askelin. Minulla oli tunne, että käyttäjärajapinta oli toimiva, mutta köpö ja viimeistelemätön. Siinä roikkui turhia valintakohtia mikä missäkin. Erityisesti minua häiritsi, että haetut viestit oli mahdollista siirtää joko postikansiotiedostoon tai normaaliin ulostuloon. En vain hahmottanut, mikä siinä oli ongelma.
"...käyttäjärajapinta on toimiva, mutta sillisalaatti - epäelegentti ja liian monia pikkuoptioita ripoteltuna ympäriinsä."
Postikansiotiedosto on aika hirviö..miten olisi postien arkistointitiedostoon tai tallennustiedostoon. Samoin 'normaali ulostulo' kuulostaa hassulta.. synnyttämiseltä.. --rhk
(If you don't care about the technicalia of Internet mail, the next two paragraphs can be safely skipped.)
- Jos et ole kiinnostunut sähköpostin teknisestä puolesta, voit huoletta hypätä kahden seuraavan kappaleen yli.
Miten olisi matkia tuota enkunkielistä sulkeisiin laittamista ajatusviivan sijaan? Tai ladonnassa jotenkin huomoida tämä tms?
What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does.
Pohtiessani SMTP-välitystä huomasin, että POP-asiakasohjelma oli yrittänyt tehdä liian montaa asiaa. Se oli tarkoitettu sekä kuljettamaan viestejä koneelta toiselle (Mail Transport Agent, MTA) että jakelemaan viestejä sähköpostilaatikoihin (Mail Delivery Agent, MDA). Hyödyntämällä SMTP-välitystä voitaisiin luopua jakelutehtävästä ja erikoistua viestien kuljetukseen. Viestit voitaisiin jakaa muille ohjelmille Sendmailin tapaan.
Ehdottaisin, että 'popclient' korvataan kaikkialla suomennoksella POP-asiakasohjelma, kun suomennos on kerran olemassa. Ks. http://en.wikipedia.org/wiki/Mail_transfer_agent ja http://en.wikipedia.org/wiki/Mail_delivery_agent - Jopi.
:Mutta popclienthan oli sen ohjelman nimi. - Jarno
"...toimittaen postia muille ohjelmille..."
Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? Especially when this means retrieved mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what we want anyway.
Miksi tapella sähköpostin jakeluun tai postilaatikkotiedostoon liittyvien lukitus- ja liitäntäongelmien kanssa, kun portti 25 on lähes varmasti käytettävissä jokaisessa koneessa, jossa hyödynnetään TPC/IP -protokollaa? Noudetut viestit voidaan joka tapauksessa käsitellä samalla tavoin kuin ulkopuoliselta lähettäjältä tulleet SMTP-viestit.
"...lukitse-ja-liitä toimintoa sähköpostilaatikossa, kun portti 25 on lähes takuuvarmasti olemassa jokaisella alustalla, jolla TCP/IP on ylipäänsä tuettuna?"
(Back to a higher level....)
- Palataanpa korkeampiin sfääreihin...
Even if you didn't follow the preceding technical jargon, there are several important lessons here. First, this SMTP-forwarding concept was the biggest single payoff I got from consciously trying to emulate Linus's methods. A user gave me this terrific idea—all I had to do was understand the implications.
Edeltäneistä ammattikielen koukeroista on siivilöitävissä muutamia tärkeitä opetuksia. Ensiksikin SMTP-viestinvälitys oli suurin yksittäinen tulos, jonka saavutin yrittämällä tietoisesti jäljitellä Linuksen toimintatapoja. Sain välitystä koskevan idean käyttäjältä, ja minun tarvitsi vain ottaa selvää, mihin kaikkeen se saattoi johtaa.
understand the implications voi ehkä kaivata paremman suomennoksen
ymmärtää sovellusala
osata soveltaa (hyvin vapaa käännös:)
ymmärtää merkitys
ymmärtää vaikutukset.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
11. Parasta on kun on omia hyviä ideoita. Toiseksi parasta on osata tunnistaa käyttäjien hyvät ideat. Joskus jälkimmäinen on parempi.
Tämä oli ennen: Seuraavaksi paras asia omien hyvien ideoiden omaamisen jälkeen on tunnistaa käyttäjiesi hyvät ideat. Joskus jälkimmäinen on parempi. (katsotaan näyttäskö paremmalta)
Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius. We can all see how well this worked for Linus!
Voit huomata piankin erään kiinnostavan seikan. Jos olet täysin ja omaa osuuttasi vähätellen rehellinen, mistä kaikesta olet velkaa muille, maailma alkaa kohdella sinua ikään kuin olisit tehnyt kaiken ominpäin. Sinua vain pidetään vaatimattomana omien lahjojesi suhteen. Kuinka hyvin se onkaan toiminut Linuksen kohdalla!
Koko kappale vaikuttaa englanninkieliseltä tekstiltä suomalaisilla sanoilla. Ainakin "sä-passiivista" voisi olla hyvä päästä eroon; kirjoitin koko kappaleen uusiksi ja otin loputkin sinä-passiivista pois 5.12.2008 (JP) --melkein hyvä, hiukan vielä viilausta.
Nähdäkseni tässä ei ole kyse sä-passiivista. Lukijaa puhutellaan suoraan, eikä sitä tarvitse välttää käännöksessäkään. - Jopi.
(When I gave my talk at the first Perl Conference in August 1997, hacker extraordinaire Larry Wall was in the front row. As I got to the last line above he called out, religious-revival style, "Tell it, tell it, brother!". The whole audience laughed, because they knew this had worked for the inventor of Perl, too.)
Kun puhuin ensimmäisessä Perl-konferenssissa elokuussa 1997, eturivissä istui Larry Wall, Perlin kehittäjä ja muutenkin hakkeri-guru vailla vertaa. Heti kun olin päässyt puhumasta vaatimattomuudesta, Larry kiljahti kuin herätyskokouksessa: "Totisesti, totisesti, veli!". Yleisöä nauratti, koska hyvin tiedettiin, että samanlainen vaatimattomuus oli siivittänyt Perlin keksijänkin mainetta.
"Extraordinaire" = ihmeellisen hyvä / taitava - laina ranskasta, tarkoittaa "vailla vertaa", "omaa luokkaansa" "Religious-revival style" uskonnollisella elpymis-tyylillä? Tarkoittaa mitä? - tarkoittaa herätysliikkeen kokouksille ominaista tyyliä "...vertaansa vailla oleva hakkeri-guru Larry Wall oli eturivissä." "...sama jekku oli toiminut myös Perlin keksijän kohdalla."
After a very few weeks of running the project in the same spirit, I began to get similar praise not just from my users but from other people to whom the word leaked out. I stashed away some of that email; I'll look at it again sometime if I ever start wondering whether my life has been worthwhile :-).
Vedettyäni projektia tässä hengessä muutaman viikon aloin saada kehuja. Niitä ei tullut pelkästään ohjelman käyttäjiltä vaan myös muilta, joille sana oli kiirinyt. Talletin osan saamistani viesteistä. Otan ne esille, jos joskus alan epäillä että elämäni on kulunut hukkaan :-).
"Laitoin talteen osan näistä sähköposteista..." -Ylimääräinen pilkku (?) pois... (JarkkoIH)
But there are two more fundamental, non-political lessons here that are general to all kinds of design.
On vielä kaksi muuta, perustuvaa laatua olevaa, ihmissuhteisiin liittymätöntä opetusta, jotka pätevät kaikkeen suunnittelutyöhön.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
12. Usein yllättävimmät ja kekseliäimmät ratkaisut löytyvät, kun tajuaa, että on käsittänyt ongelman luonteen väärin.
I had been trying to solve the wrong problem by continuing to develop popclient as a combined MTA/MDA with all kinds of funky local delivery modes. Fetchmail's design needed to be rethought from the ground up as a pure MTA, a part of the normal SMTP-speaking Internet mail path.
Olin yrittänyt ratkaista väärää ongelmaa kehittämällä POP-asiakasohjelmaa MTAn ja MDAn yhdistelmänä, jossa höysteenä olisi vielä jos jonkinlaisia jakelutapoja. Fetchmailin rakenne piti miettiä uusiksi. Siitä piti tehdä puhdas viestinkuljetusohjelma (MTA), osa normaalia SMTP:hen perustuvaa viestinvälityspolkua.
"osana normaalia SMTP:tä puhuvaa Internet-postin reittiä."
When you hit a wall in development—when you find yourself hard put to think past the next patch—it's often time to ask not whether you've got the right answer, but whether you're asking the right question. Perhaps the problem needs to be reframed.
Kun ohjelmistokehityksessä törmää seinään, kun huomaa vaikeaksi ajatella seuraavaa korjausta pidemmälle, voi olla aika pohtia, kysyykö oikeita kysymyksiä eikä sitä, onko löytänyt oikeita vastauksia. Ehkäpä ongelma pitääkin muotoilla uudestaan.
Kaipaisi stilisointia, otin sä-passiivin pois, mutta ei se täydellinen noinkaan ole. Lauserakenne on vähän hankala puolipisteineen. Kenties suomennoksen pitäisi olla radikaalimpi?
Well, I had reframed my problem. Clearly, the right thing to do was (1) hack SMTP forwarding support into the generic driver, (2) make it the default mode, and (3) eventually throw out all the other delivery modes, especially the deliver-to-file and deliver-to-standard-output options.
No, rajasin siis ongelman uudestaan. Selvästikin oli tarpeen (1) virittää SMTP-välitys ohjelman perustaan, (2) tehdä siitä oletusvaihtoehto, ja (3) lopulta luopua muista jakelumuodoista, etenkin vaihtoehdoista 'liitä tiedostoon' ja 'toimita standardiulostuloon (STD-OUT)'.
I hesitated over step 3 for some time, fearing to upset long-time popclient users dependent on the alternate delivery mechanisms. In theory, they could immediately switch to .forward files or their non-sendmail equivalents to get the same effects. In practice the transition might have been messy.
Epäröin muista jakelumuodoista luopumista jonkin aikaa. Monet käyttäjät olivat tottuneet niihin. Teoriassa he olisivat voineet siirtyä hyödyntämään Sendmailin .forward-tiedostoja tai muita vaihtoehtoja muutoksen jälkeen. Tosin käytännössä siirtyminen ei ehkä olisi ollut kovin yksinkertaista.
.forward-tiedostosta ks. http://www.feep.net/sendmail/tutorial/intro/forward.html - Jopi.
But when I did it, the benefits proved huge. The cruftiest parts of the driver code vanished. Configuration got radically simpler—no more grovelling around for the system MDA and user's mailbox, no more worries about whether the underlying OS supports file locking.
Kuitenkin kun toteutin muutoksen, sen edut osoittautuivat huikeiksi. Ajuriohjelman tahmaisimmista osista päästiin eroon, ja asetusten muuttamisesta tuli paljon yksinkertaisempaa. Enää ei tarvinnut hakea epätoivoisesti järjestelmän postinjakelua ja käyttäjän postilaatikkoa, eikä enää tarvinnut huolehtia, tukeeko käyttäjän käyttöjärjestelmä tiedostojen lukitsemista.
Tarkistettava: Crufty, grovelling for crufty = epämääräisimmin toteutetut osat, (Internet) poorly built and over-complex, and unpleasant, kts. http://en.wiktionary.org/wiki/crufty
Also, the only way to lose mail vanished. If you specified delivery to a file and the disk got full, your mail got lost. This can't happen with SMTP forwarding because your SMTP listener won't return OK unless the message can be delivered or at least spooled for later delivery.
Samalla päästiin eroon ainoasta viasta, jossa sähköposteja saattoi hävitä. Aiemmin jakelun saattoi ohjata tiedostoon, ja jos kiintolevy täyttyi, postia hävisi. Tätä ei voi tapahtua SMTP-välityksessä, koska SMTP-ohjelma kuittaa vain, jos viesti jaetaan perille tai vähintäänkin tallennetaan myöhempää jakelua varten.
Also, performance improved (though not so you'd notice it in a single run). Another not insignificant benefit of this change was that the manual page got a lot simpler.
Myös ohjelman suorituskyky parani, vaikkakaan ei niin merkittävästi että sitä huomaisi yksittäisessä ajossa. Merkityksetöntä ei ollut sekään, että käyttöohjeesta tuli paljon yksinkertaisempi.
huima? minkä muun adjektiivinen tohon vois laittaa? laaja yksinkertaistuminen?
Later, I had to bring delivery via a user-specified local MDA back in order to allow handling of some obscure situations involving dynamic SLIP. But I found a much simpler way to do it.
Myöhemmin minun täytyi palauttaa mahdollisuus jakaa postia käyttäjän omalta koneelta valitseman jakeluohjelman kautta. Sitä tarvittiin eräissä erikoistilanteissa, joissa käytettiin dynaamista SLIPiä (Serial Line Internet Protocol). Tuossa vaiheessa keksin yksinkertaisen tavan ominaisuuden toteutukseen.
The moral? Don't hesitate to throw away superannuated features when you can do it without loss of effectiveness. Antoine de Saint Exupéry (who was an aviator and aircraft designer when he wasn't authoring classic children's books) said:
Opetus? Ei kannata epäröidä vanhentuneista ominaisuuksista luopumista, jos sen voi tehdä heikentämättä tehokkuutta. Antoine de Saint-Exupéry, joka oli lentäjä ja lentokonesuunnittelija silloin, kun ei kirjoittanut lastenkirjaklassikoita, sanoi:
Englantisarakkeeseen korjattu en-wikin mukainen muoto.
13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
13. "Suunnittelussa täydellisyyttä ei saavuteta silloin, kun ei ole enää mitään lisättävää, vaan silloin kun ei ole enää mitään pois otettavaa."
pois otettavaa -> pois tettavaa = poistettavaa
When your code is getting both better and simpler, that is when you know it's right. And in the process, the fetchmail design acquired an identity of its own, different from the ancestral popclient.
Kun ohjelmakoodi tulee samalla kertaa paremmaksi ja yksinkertaisemmaksi, tietää että on oikealla tiellä. Tällaisessa prosessissa Fetchmailin rakenne sai oman identiteettinsä, joka oli erilainen kuin antiikkisen POP-asiakasohjelman.
"... erillisen popclientista perittyyn identiteettiin nähden."
It was time for the name change. The new design looked much more like a dual of sendmail than the old popclient had; both are MTAs, but where sendmail pushes then delivers, the new popclient pulls then delivers. So, two months off the blocks, I renamed it fetchmail.
Oli aika vaihtaa ohjelman nimi. Uudistunut ohjelma muistutti Sendmailin kaksoiskappaletta paljon enemmän kuin vanha POP-asiakasohjelma. Molemmat ovat jakeluohjelmia, mutta siinä missä Sendmail työntää, uusi POP-ohjelma vetää viestejä ennen jakelua. Kaksi kuukautta lähtölaukauksen jälkeen nimesin ohjelman Fetchmailiksi.
There is a more general lesson in this story about how SMTP delivery came to fetchmail. It is not only debugging that is parallelizable; development and (to a perhaps surprising extent) exploration of design space is, too. When your development mode is rapidly iterative, development and enhancement may become special cases of debugging—fixing `bugs of omission' in the original capabilities or concept of the software.
Fetchmailin kehitystarina sisältää yleisluonteisenkin opetuksen. Rinnakkaistaminen ei ole mahdollista pelkästään virheiden korjaamisessa. Se on mahdollista myös ohjelmiston kehittämisessä ja ehkäpä yllättävässäkin määrin myös suunnitteluavaruuden eri mahdollisuuksien luotaamisessa. Jos ohjelmistoa kehitetään nopeissa sykleissä, ohjelmiston kehittämisestä ja laajentamisesta voi tulla eräänlaista virheenkorjausta, huomiotta jääneisiin mahdollisuuksiin tarttumista.
Iterointi ei tarkoita pelkkää toistoa, vaan myös sitä, että tulos lähenee tai tarkentuu jokaisella toistokierroksella. - Jopi
design space=suunnitteluavaruus vai design space=suunnittelurakenne
Ei ainoastaan virheiden etsintä, vaan kehitys ja (ehkäpä yllättävässäkin määrin) suunnittelutilan tutkimus on myös rinnakkaistettavissa.
Even at a higher level of design, it can be very valuable to have lots of co-developers random-walking through the design space near your product. Consider the way a puddle of water finds a drain, or better yet how ants find food: exploration essentially by diffusion, followed by exploitation mediated by a scalable communication mechanism. This works very well; as with Harry Hochheiser and me, one of your outriders may well find a huge win nearby that you were just a little too close-focused to see.
Jopa ohjelman perusrakenteen suunnittelussa voi olla hyödyllistä, että suunnitteluavaruutta tutkii monia apukehittäjiä edeten omia satunnaisia polkujaan. Tilannetta voi verrata siihen, miten vesirapakon vesi löytää valumisreitin eteenpäin, tai paremminkin, miten muurahaiset löytävät ravintoa. Ne etsivät ruokaa hajautumalla maastoon, ja hyödyntävät löytöjä viestittämällä niistä toisilleen. Se toimii todella hyvin. Joku sinunkin tiedustelijoistasi voi tehdä suuren löydön sillä aikaa, kun sinun huomiosi kiinnittyy päivänpolttaviin asioihin. Niin kävi Harry Hochheiserille ja minulle.
Outriders suomennos, samoinkuin koko loppu kaipanee parannusta. "...yksi tiedustelijoistasi voi tehdä lähettyvillä valtavan läpimurron, jota sinä et liialliselta lähietäisyydeltä kyennyt näkemään.":