Page suivante Page précédente Table des matières

7. Fetchmail grandit

Me voici donc avec une conception propre et novatrice, un code dont je savais qu'il fonctionnait bien puisque je l'utilisais tous les jours, et une liste bêta bourgeonnante. Je me rendis peu à peu compte que je n'étais plus engagé dans une bidouille personnelle et triviale que d'autres pourraient éventuellement trouver utile. J'étais le responsable d'un programme réellement utile à tout bidouilleur possédant une babasse sous Unix et une connexion par SLIP/PPP.

Quand j'y eus injecté la fonctionnalité de SMTP, il surpassa tellement ses concurrents qu'il se mua en un ``programme de référence'', un de ces programmes classiques qui remplissent si bien leur rôle qu'il élimine toute compétition parce qu'on en oublie complètement les autres solutions, au lieu de simplement les laisser de côté.

Je ne pense pas qu'on puisse vraiment viser ou planifier un tel but. On y est attiré par des idées de conception si puissantes qu'après coup les résultats paraissent tout naturels, inévitables, prédestinés. La seule manière de tomber sur ce genre d'idées est d'avoir beaucoup d'idées -- ou d'avoir assez de discernement pour reconnaître les bonnes idées des autres, même si elles vous mènent plus loin que vous ne pensiez aller.

Andrew Tanenbaum eut l'idée originale de construire un Unix simple en natif pour le 386, afin de l'utiliser comme outil pour l'enseignement. Linus Torvalds a poussé le concept de Minix bien plus loin sans doute que ce qu'Andrew avait en tête -- et il le transforma en quelque chose de merveilleux. De la même manière (mais pas à la même échelle), j'avais pris quelques idées de Carl Harris et de Harry Hochheiser et je les avais exploitées à fond. Aucun de nous n'est 'original' de la manière, romantique, dont les gens imaginent le génie. Mais la majeure partie des sciences, de l'ingéniérie et du développement logiciel n'est pas le fruit du génie à l'état pur, malgré ce que peuvent laisser croire les mythes des bidouilleurs.

Les résultats furent à peu près une excitation identique -- en fait, le genre de choses dont tous les bidouilleurs rêvent ! Et ils signifiaient simplement qu'il me faudrait être encore plus exigeant avec moi-même. Pour rendre fetchmail aussi bon que j'entrevoyais qu'il pouvait l'être, il ne faudrait plus me contenter d'écrire du code répondant à mes propres besoins, il me faudrait prendre en compte les désirs et les souhaits des autres pour des fonctionnalités que je n'utiliserais pas. Tout en gardant le programme simple et robuste.

Le premier ajout que j'écrivis après cela, et il fut de taille, fut la possibilité de distribuer du courrier dans des 'immeubles' (multidrop) -- récupérer du courrier à partir d'une boîte aux lettres correspondant à une adresse commune, dans laquelle s'étaient accumulés des plis, et redistribuer chacun d'entre eux dans les boîtes personnelles de leur véritable destinataire.

J'ai en partie accepté d'ajouter le multidrop parce qu'on me le réclamait à grands cris, mais surtout parce que je pensais qu'il m'aiderait à traquer les bogues subsistant dans le code 'single-drop' (mono-destinataire) en me forçant à gérer les adresses dans toute leur généralité. C'est ce qui s'est passé. Il me fallut extrêmement longtemps pour gérer la syntaxe du RFC 822

NdT les RFC sont des protocoles décidés en commun sur Internet. Ce sont les initiales de Request For Comments, littéralement ``(nous) réclamons des commentaires (sur ce qui suit)''.
, non qu'il contienne des choses extrêmement compliquées, mais que dans son ensemble il fait intervenir un enchevêtrement de détails un peu tordus.

Mais l'adressage multidrop s'avéra également être une excellente décision de conception. Voici comment je m'en rendis compte:

14. Tout outil doit être utile par rapport aux utilisations qu'il a été prévu d'en faire. Mais on reconnaît un outil vraiment excellent au fait qu'il se prête à des usages totalement insoupçonnés.

L'utilisation inattendue d'un fetchmail multi-destinataires est la gestion de listes de courrier électronique où la liste est conservée et où le développement des alias est fait du côté client de la connexion SLIP/PPP. Cela signifie qu'on peut modérer une liste de courrier électronique à partir d'une machine personnelle, via un compte chez un fournisseur de services pour Internet

NdT ISP, parfois FAI
sans devoir accéder sans cesse aux fichiers d'alias du fournisseur.

Une autre amélioration importante exigée par mes bêta-testeurs, fut la possibilité d'utiliser le format MIME en 8 bits. Cela fut assez simple à faire, parce que j'avais pris soin de laisser mon code compatible 8 bits. Non que je prévoyais ce souhait des utilisateurs, mais plutôt en accord avec une autre règle:

15. Quand vous écrivez un logiciel jouant le rôle d'une passerelle quelconque, prenez soin de perturber le moins possible le flot de données -- et ne perdez *jamais* d'éléments d'information, à moins que la machine destinataire vous y oblige !

Si je n'avais pas obéi à cette règle, le support du MIME en 8 bits aurait été difficile à implanter et instable. En l'état, il me suffit de lire le RFC 1652 et d'ajouter un petit peu de logique triviale pour la génération des en-têtes.

Quelques utilisateurs européens m'ont ennuyé jusqu'à ce que j'ajoute une option pour limiter le nombre de messages transférés à chaque session (pour qu'ils puissent contrôler le prix de la communication téléphonique, sur leur onéreux réseau). J'ai mis du temps à m'y résoudre, et aujourd'hui encore je n'en suis pas très content. Mais quand vous êtes au service du monde entier, il vous faut écouter vos consommateurs -- le fait qu'ils ne vous paient pas en monnaie sonnante et trébuchante ne change rien à l'affaire.


Page suivante Page précédente Table des matières