La cattedrale e il bazaar/Popclient diventa Fetchmail
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Quando una rosa non è una rosa? | Fetchmail diventa adulto | ► |
Il vero punto di svolta del progetto ebbe luogo quando Harry Hochheiser mi spedì il codice iniziale per fare il forward alla porta SMTP della macchina client. Mi sono reso immediatamente conto che l’implementazione affidabile di tale funzione avrebbe reso pressoché obsoleta ogni altra modalità di consegna della posta.
Per molte settimane mi ero messo a giocare con l’interfaccia di fetchmail, passabile ma disordinata – poco elegante e con troppe opzioni sparse tutt’intorno. Tra queste mi davano particolarmente fastidio, anche senza capire perché, quelle utilizzate per trasferire la posta prelevata in una certa mailbox o altrove.
Quel che mi veniva in mente pensando alla funzione del “SMTP forwarding” era che popclient voleva cercare di far troppe cose. Era stato ideato per essere sia un “mail transport agent” (MTA) sia un “mail delivery agent” (MDA) a livello locale. Con il forward SMTP avrebbe potuto smettere di essere un MDA per divenire un puro MTA, trasferendo ad altri programmi la posta per la consegna locale, proprio come fa sendmail.
Perché darsi da fare a sistemare le complesse configurazioni per un MDA o le impostazioni per le mailbox, quando innanzitutto è quasi sempre garantito che la porta 25 rimane disponibile per questo su ogni piattaforma con supporto TCP/IP? Soprattutto quando ciò significa che i messaggi prelevati appariranno come posta SMTP normalmente inviata dal mittente, che è poi quel che stiamo cercando di ottenere.
Ci sono diverse lezioni da trarre a questo punto. Primo, l’idea del “SMTP forwarding” era la prima grossa ricompensa per aver tentato coscientemente di emulare i metodi di Linus. Era stato un utente a suggerirmi questa fantastica idea – non mi restava che comprenderne le implicazioni.
11. La cosa migliore, dopo l’avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
Fatto interessante, è facile scoprire che se sei completamente onesto e autocritico su quanto è dovuto agli altri, il mondo intero ti tratterà come se ogni bit di quell’invenzione fosse opera tua, mentre impari a considerare con sempre maggior modestia il tuo genio innato. Abbiamo visto come tutto ciò abbia funzionato a meraviglia con Linus!
(Quando ho presentato questo scritto alla conferenza su Perl dell’Agosto 1997, in prima fila c’era Larry Wall. Non appena sono arrivato al punto di cui sopra, ha intonato in stile revival-religioso, “Diglielo, diglielo, fratello!” Tutti i presenti si son messi a ridere, perché sapevano come ciò avesse funzionato bene anche per l’inventore di Perl.)
Dopo aver lavorato sul progetto nello stesso spirito per alcune settimane, mi son visto arrivare lodi simili non soltanto dagli iscritti alla lista ma anche da altre persone che venivano a sapere della cosa. Ho conservato qualche email; forse me le andrò a rileggere nel caso iniziassi a chiedermi se la mia vita abbia mai avuto un qualche valore :-).
Ma ci sono altre due lezioni da trarre, più fondamentali e non politiche, buone per ogni tipo di design.
12. Spesso le soluzioni più interessanti e innovative arrivano dal fatto di esserti reso conto come la tua concezione del problema fosse errata.
Avevo cercato di risolvere il problema sbagliato continuando a lavorare su popclient in quanto combinazione MTA/MDA con tutte le possibili modalità di consegna della posta. Il design di fetchmail aveva bisogno di essere reimpostato dall’inizio come un puro MTA, a parte il normale percorso della posta relativo a SMTP.
Quando sbatti la testa contro il muro nel lavoro di programmazione – quando cioè non riesci più a pensare alla prossima “patch” – spesso è ora di chiedersi non se hai la risposta giusta, ma se ti stai ponendo la giusta domanda. Forse bisogna inquadrare nuovamente il problema.
Be’, mi toccò inquadrare meglio il problema. Chiaramente la cosa giusta da fare era (1) posizionare il supporto per il “SMTP forwarding” nel driver generico, (2) farla diventare la funzione default, (3) sbarazzarsi di tutte le altre modalità di consegna della posta, specialmente le opzioni “deliver-to-file” e “deliver-to-standard-output”.
Per qualche tempo ho esitato a compiere il passo (3), temendo di avvilire quanti usavano da molto tempo popclient proprio per i diversi meccanismi di consegna. In teoria, avrebbero potuto immediatamente passare ai file “.forward” oppure agli equivalenti “non-sendmail” per ottenere il medesimo effetto. In pratica, però, tale transizione sarebbe risultata impraticabile.
Quando mi decisi comunque a farlo, ne risultarono enormi benefici. Le parti più confuse del codice del driver scomparvero. La configurazione divenne radicalmente più semplice – niente più girovagare nel sistema MDA e nella mailbox, niente più preoccupazioni per vedere se il sistema operativo supportasse o meno il blocco dei file.
Venne anche eliminata l’unica possibilità di perdere dei messaggi. Se, specificando la consegna in un file, il disco è pieno, la posta va perduta. Impossibile che ciò accada con il “SMTP forwarding” perché l’altro SMTP in ascolto non accetterà l’OK a meno che il messaggio non possa essere correttamente consegnato o almeno filtrato per il prelievo successivo.
Inoltre, le prestazioni complessive risultarono migliorate (anche se così non sembra quando lo si fa girare una sola volta). Altro beneficio non insignificante del cambiamento fu che la chiamata manuale risultò assai più semplificata.
In seguito fui costretto a reintrodurre la funzione di consegna tramite un MDA locale specificato dall’utente, per consentire la gestione di strane situazioni relative allo SLIP dinamico. Ma riuscii a farlo in maniera più semplice.
Morale? Non esitare a buttar via opzioni inanellate una sull’altra quando puoi rimpiazzarle senza perdere in efficienza. Diceva Antoine de Saint-Exupéry (aviatore e designer di aerei, quando non scriveva libri per bambini):
13. “La perfezione (nel design) si ottiene non quando non c’è nient’altro da aggiungere, bensì quando non c’è più niente da togliere.”
Quando il codice diventa migliore e più semplice, allora vuol dire che va bene. E nel processo, il design di fetchmail acquistò una sua propria identità, diversa dal popclient originario.
Era giunta l’ora di cambiar nome. Il nuovo design assomigliava più a sendmail di quanto lo fosse il vecchio popclient; entrambi sono MTA, ma mentre sendmail spinge e poi consegna, il nuovo popclient tira e poi consegna. Così, a due mesi dai blocchi di partenza, decisi di dargli il nuovo nome, fetchmail.