[go: up one dir, main page]

Pergi ke kandungan

Katedral dan Bazar/Mel Perlu Sampai

Daripada Wikibuku

Saya mengendali bahagian teknikal sebuah pembekal Internet akses percuma kecil semenjak tahun 1993 yang dipanggil Chester County InterLink (CCIL) di West Chester, Pennsylvania. Saya pengasas bersama CCIL dan menulis perisian papan buletin multipengguna yang unik – anda boleh periksa perisian tersebut dengan telnet di locke.ccil.org. Hari ini perisian ini menyokong tiga ribu pengguna dengan 30 talian. Kerja yang saya buat itu membenarkan saya mengakses Net 24 jam melalui talian 56K CCIL – malah tugas saya memerlukannya!.

Saya menjadi biasa dengan e-mel serta Internet. Saya mendapati keperluan untuk membuat telnet kepada locke untuk memeriksa e-mel menjengkelkan. Apa yang saya mahu ialah untuk e-mel saya dikirim pada snark (sistem rumah saya) agar saya dapat dimaklumkan apabila ia sampai dan dapat mengendalikannya dengan perkakas lokal saya. Protokol pemajuan mel natif Internet, SMTP (Simple Mail Transfer Protocol) (harfiah, "Protokol Pemindahan Mel Mudah"), tidak sesuai kerana ia hanya berfungsi dengan baik apabila mesin-mesin dihubungkan sepenuh masa, sementara mesin peribadi saya tidak sentiasa berada di Internet, dan tidak memiliki alamat IP pegun. Apa yang saya perlukan ialah sebuah program yang dapat berhubung melalui talian dailan berjeda dan menarik e-mel saya agar dikirim secara lokal. Saya tahu yang benda sebegini wujud, dan kebanyakannya menggunakan protokol aplikasi mudah yang dipanggil POP (Post Office Protocol) (harfiah, "Protokol Pejabat Pos"). POP sekarang disokong secara luas oleh kebanyakan klien e-mel biasa, tapi pada waktu itu ia tidak terbina dalam pembaca mel yang saya guna. Saya perlukan sebuah klien POP3. Jadi saya pergi ke Internet dan mengetemui satu. Sebenarnya, saya mengetemui tiga atau empat. Saya mengguna satu daripada klien itu buat seketika, akan tetapi ia tidak memiliki satu ciri yang agak ketara, kebolehan untuk menggodam alamat-alamat yang terdapat pada e-mel yang dikirim agar jawapan atau e-mel balas dapat berfungsi dengan betul. Masalahnya begini: katakan seorang bernama "joe" pada locke menghantar e-mel kepada saya. Jika saya mengambil e-mel itu pada snark dan kemudian mencuba untuk menjawabnya, penghantar mel saya akan dengan gembira cuba mengirimnya kepada seorang "joe" yang tidak wujud di snark. Menyunting alamat balas secara insani agar menyisipkan <@ccil.org> menjadi sebuah kerja yang menjengkelkan dengan cepat.

Dengan semangat yang sama, saya pun pergi mencari utiliti POP yang sudahpun dikod dengan agak baik, untuk digunakan sebagai asas pembangunan. Tradisi perkongsian kod dalam alam Unix memang mesra dengan penggunaan semula kod (inilah sebabnya projek GNU memilih Unix sebagai sistem operasi (OS), mahupun tidak berapa yakin dengan OS itu sendiri). Alam Linux sudahpun membawa tradisi ini hampir ke had teknologinya; ia memiliki beberapa terabait sumber-sumber terbuka yang tersedia. Justeru, meluangkan masa untuk mencari kod yang "hampir sesuai" hasil usaha orang lain berkemungkinan besar akan mendatangkan hasil baik dalam alam Linux berbanding tempat lain. Dan ia membuahkan hasil buat saya. Bersama-sama kod yang saya jumpa sebelum ini, pencarian kedua saya mengetemukan sembilan calon – 'fetchpop', 'PopTart', 'get-mail', 'gwpop', 'pimp', 'pop-perl', 'popc', 'popmail' dan 'upop'. Perisian pertama yang saya pilih ialah 'fetchpop' yang ditulis Seung-Hong Oh. Saya meletakkan ciri penulisan-semula-pengepala ke dalam kodnya, dan membuat beberpa penambahbaikan yang diterima pengarang buat penegeluaran versi 1.9 perisian. Beberapa minggu kemudian, saya terjumpa kod 'popclient' yang ditulis Carl Harris, dan mendapati bahawa saya ada masalah. Mahupun 'fetchpop' mengandungi beberapa idea asli yang baik (misalnya, mod daemon latar), ia hanya dapat mengendalikan POP3 dan dikod dengan cara amatur (pada masa itu Seung-Hong seorang pengatur cara yang cerdik akan tetapi tidak berpengalaman, dan kedua-dua ciri dapat dilihat dalam kod). Kod Carl lebih baik, agak profesional dan kukuh, akan tetapi programnya kurang beberapa ciri 'fetchpop' yang penting dan agak sukar diimplemtasi (termasuk ciri yang saya kod sendiri). Teruskan atau tukar? Jika saya tukar, saya akan membuang kod yang sudahpun saya tulis untuk diganti dengan asas pembangunan yang lebih baik. Satu motif praktikal untuk menukar program ialah kehadiran sokongan multiprotokol. POP3 merupakan protokol pelayan post-office yang paling biasa digunakan, akan tetapi ia bukan protokol yang tunggal. 'Fetchpop' dan pesaing lain tidak melaksanakan POP2, RPOP, ataupun APOP, dan saya sudahpun memikirkan, mahupun masih kabur, tentang kemungkinan menambah IMAP (Internet Message Access Protocol "Protokol Capaian Mesej Internet", protokol post-office yang bahay direka dan yang paling berkuasa) untuk suka-suka.