Atpakaļ
Katedrāle un tirgus: Kad roze nav roze? | Tālāk
Katedrāle un tirgus: Fetchmail aug |
Popclient kļūst par fetchmail
Kad Harijs Hočheizers (
Harry Hochheiser) atsūtīja man sākotnējo kodu vēstuļu pārsūtīšanai uz klienta mašīnas SMTP portu, tas bija nopietns pagrieziena punkts mūsu projektā. Es praktiski uzreiz sapratu, ka droša šīs iespējas implementācijas padarīs visus citus paņēmienus par novecojušiem.
Daudzas nedēļas es biju ķimerējies ar pakāpeniskiem fetchmail uzlabojumiem, jūtot, ka saskarne ir lietojama, bet netīra, neizkopta un ar pārāk daudz nevajadzīgām iespējām. Piemēram, iespēja novirzīt savākto vēstuli failā vai standarta izejā mani tracināja, lai gan es nezināju, kāpēc.
(Ja jūs neinteresējaties par e-pasta tehniskajām detaļām, nākošās divas rindkopas droši varat izlaist.)
Kad es domāju par SMTP pārsūtīšanu, es sapratu, ka popclient darīja pārāk daudz. Tas bija izstrādāts gan kā pasta pārsūtīšanas aģents (
Message Transfer Agent - MTA), gan kā lokālās piegādes aģents (
Message Delivery Agent - MDA). Bet, ja ir SMTP pārsūtīšana, tad var atteikties no MDA lietām un kļūt par tīru MTA, lokālai apstrādei pastu nododot citām programmām, kā to dara sendmail.
Kam vajadzīga visa tā sarežģītība ar pastkastīti un pasta nosūtīšanu, ja 25. ports ir atvērts praktiski visām sistēmām, kas darbojas ar TCP/IP? Īpaši tad, ja saņemtā vēstule izskatās tieši tā, kā sākotnējais nosūtītājs to ir nosūtījis, ko mēs patiesībā arī vēlamies.
(Atpakaļ uz augstāku līmeni ...)
Pat ja jūs neizpratāt iepriekšējo žargonu, tur ir vairāki svarīgi momenti. Pirmkārt, SMTP pārsūtīšanas koncepcija bija pirmais labums, ko es ieguvu, apzināti atkārtojot Linusa paņēmienus. Lietotājs man ieteica kolosālu ideju, viss, ko man vajadzēja izdarīt, bija novērtēt sekas.
11. Lai būtu labas idejas, otra svarīgākā lieta ir pamanīt tās, ko iesaka lietotāji. Otrās dažkārt ir labākas.
Pats interesantākais -- jūs ātri vien atklāsiet, ka, lai arī cik pieticīgs un patiess jūs būsiet sacīdams, ka lielu pateicību parādā jūs esat citiem cilvēkiem, kopumā pasaule tik un tā uzskatīs, ka ikvienu izgudrojuma bitu jūs esat atklājis pašrocīgi, un tikai pārlieku lielā kautrība jums neļauj atklāt savu iedzimto ģēniju. Mēs visi redzam, kā tas notika ar Linusu!
(Kad es uzstājos ar savu runu pirmajā Perl konferencē 1997. gada augustā, izcilais hakeris Lerijs Vols (
Larry Wall) sēdēja pirmajā rindā. Kad es nonācu līdz šim tekstam, viņš iesaucās reliģiozā balsī "Fleitē, fleitē, brāl!''. Auditorija iesmējās, jo viņi zināja, ka tā notika arī ar Perl izgudrotāju.)
Kad mēs bijām turpinājuši projektu tādā pašā garā vēl pāris nedēļas, es sāku saņemt līdzīgas uzslavas ne tikai no saviem lietotājiem, bet arī no citiem cilvēkiem visā pasaulē. Dažas no tām es esmu noglabājis. Es tās atkal kādreiz apskatīšu, kad man uznāks pārdomas, vai mana dzīve nav bijusi veltīga :-).
Bet ir vēl svarīgāka, nepolitiska mācība, kas ir spēkā jebkuram dizainam.
12. Parasti vispārsteidzošākie un radošākie risinājumi rodas no atklāsmes, ka jūsu problēmas nostādne ir bijusi nepareiza.
Es biju mēģinājis risināt nepareizu problēmu, turpinot izstrādāt popclient kā apvienotu MTA/MDA ar visiem jocīgajiem lokālās piegādes veidiem. Fetchmail dizainu vajadzēja pārdomāt no jauna kā tīru MTA, un daļu no pasta ceļa normālā SMTP-runājošā Internetā.
Ja jūs esat uzdūries sienai un jums ir grūti izlaist nākamo laidienu -- ir laiks domāt ne par to, vai ir iegūta pareizā atbilde, bet gan -- vai ir uzdots pareizais jautājums. Iespējams, problēmas robežas ir jāpārsprauž.
Labi, es pārskatīju problēmu. Acīmredzot, pareizais veids bija:
- ieķimerēt SMTP pārsūtīšanas atbalstu vispārīgā draiverī,
- padarīt to par noklusēto režīmu,
- vēlāk izmest ārā visus pārējos piegādes veidus, īpaši -- iespējas piegādāt failā un standarta izejā.
Ilgu laiku es baidījos spert 3. soli, baidoties sarūgtināt ilgstošos popclient lietotājus, kas bija atkarīgi no alternatīviem piegādes veidiem. Teorētiski viņi varētu momentā pārslēgties uz
.forward failiem vai citiem ne-sendmail analogiem, lai iegūtu to pašu. Praksē šāda pāreja varētu būt grūta.
Bet, kad es to izdarīju, ieguvums bija milzīgs. Visriebīgākās koda daļas pazuda. Konfigurēšana kļuva daudz vienkāršāka -- vairs nevajadzēja pielīst sistēmas MDA un lietotāju pastkastēm, nevajadzēja uztraukties par nepieciešamo OS atbalstu failu bloķēšanai.
Pazuda arī vienīgā iespēja pazaudēt vēstuli. Ja jūs bijāt norādījis piegādāt vēstuli failā un disks pārpildījās, jūsu vēstule pazuda. Tas nevar notiks ar SMTP pārsūtīšanu, jo SMTP klausītājs neatgriež OK tikmēr, kamēr vēstule nav saņemta vai vismaz ieritināta buferī vēlākai piegādei.
Uzlabojās arī ātrdarbība (gan ne tik ļoti, lai to pamanītu vienreiz palaižot). Vēl viens ne tik svarīgs ieguvums bija tas, ka arī rokasgrāmata kļuva daudz vienkāršāka.
Vēlāk man tomēr vajadzēja ieviest lietotāja specifisku lokālo MDA, lai varētu apstrādāt dažus retus gadījumus, iesaistot dinamisko SLIP. Bet es atradu daudz vienkāršāku veidu, kā to izdarīt.
Morāle? Nebaidieties izmest novecojušas iespējas, ja netiek zaudēta efektivitāte. Antuans de Sent-Ekziperī (
Antoine de Saint-Exupéry, kas bija lidotājs un lidmašīnu izgudrotājs, kad netērēja laiku bērnu grāmatām) teica:
13. Perfektums (dizainā) nav tad, kad jūs vairs neko nevarat pielikt klāt, bet gan tad, kad vairs nav, ko noņemt nost.
Kad jūsu kods paliek gan labāks, gan vienkāršāks,
ziniet -- tas ir pareizi. Un tā pamazām fetchmail dizains ieguva savādāku identitāti nekā viņa sencis popclient.
Tas bija laiks nosaukuma maiņai. Jaunais dizains bija nevis vecais popclient, bet drīzāk gan sendmail dvīnis -- abi ir MTA, bet, ja sendmail nosūta vēstules citam resursdatoram, tad jaunais popclient saņem vēstules no cita resursdatora. Tā divus mēnešus pēc pārbūves es to pārsaucu par fetchmail.
Tajā, kā SMTP pārsūtīšana kļuva par fetchmail, ir vēl viena vispārīgāka mācība. Tā nav tikai atkļūdošana, kas ir paralelizējama, izstrādes un (iespējams, pārsteidzošs paplašinājums) arī dizaina telpu meklējumi. Ja jūsu izstrādes stils ir ātri iteratīvs, jaunās iespējas un uzlabojumi var kļūt par speciāliem "neuzmanības kļūdu" labojumiem programmas esošajā dizainā vai iespējās.
Pat ar labu dizainu ir ļoti vērtīgi, ja ir daudz līdzizstrādātāju, kas brīvi pārskata jūsu produkta dizaina telpu. Apmēram tā, kā dresēts suns atrod gāzes noplūdi, vai labāk -- kā termīti atrod barību -- izpēte notiek ar vienkāršas difūzijas palīdzību, kas tiek izmantota un vadīta ar mērogojamu sadarbības mehānismu. Tas strādā ļoti labi, arī ar Hariju Hočheizeru un mani -- kāds no mūsu klejotājiem atrod ko ļoti labu pavisam tuvu tam, kam mēs esam pievērsušies pārāk pamatīgi, lai to ieraudzītu paši.
Atpakaļ
Katedrāle un tirgus: Kad roze nav roze? | Tālāk
Katedrāle un tirgus: Fetchmail aug |