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

6. Et popclient devint fetchmail

Le projet prit un virage radical le jour où Harry Hochheiser m'envoya un premier jet de son code destiné à faire suivre le courrier sur le port SMTP de la machine faisant tourner le client. J'ai réalisé pratiquement tout de suite qu'une implantation fiable de cette fonctionnalité rendrait pratiquement obsolètes tous les autres modes de distribution du courrier.

Cela faisait plusieurs semaines que je peaufinais fetchmail, pas à pas, tout en trouvant mon interface fonctionnelle mais un peu pataude -- inélégante et truffée de trop nombreuses options exiguës qui sortaient de toutes parts. J'étais particulièrement turlupiné par les options proposant de déposer le courrier récupéré dans un fichier boîte aux lettres ou sur la sortie standard, sans trop savoir pourquoi.

Je compris, quand l'idée de faire suivre le courrier sur le port SMTP traversa mon esprit, que popclient cherchait à trop en faire. Il avait été conçu pour jouer à la fois le rôle de la Poste (MTA, agent de transport du courrier) et du facteur (MDA, agent de distribution du courrier). En choisissant la solution SMTP, il n'aurait plus à s'occuper de tout ce qui est MDA et pourrait se concentrer sur le côté MTA, en passant le relais à d'autres programmes pour la distribution en local, tout comme sendmail le fait.

Pourquoi s'encombrer de toute la complexité inhérente à la configuration d'un facteur, pourquoi verrouiller un fichier boîte aux lettres, y ajouter du courrier, alors que le port 25 nous tendait les bras de façon pratiquement assurée sur toute plate-forme proposant TCP/IP depuis toujours ? Surtout que choisir cette solution garantit au courrier récupéré sa ressemblance avec du courrier normalement envoyé par son véritable auteur via SMTP, et que c'est exactement ce que nous cherchions.

Il y a plusieurs morales à cette histoire. Tout d'abord, l'idée de faire suivre le courrier vers le port SMTP fut le plus grand profit que je tirai de la tentative consciente de copier les méthodes de Linus. C'est un utilisateur qui m'a soufflé cette idée formidable -- et je n'ai eu qu'à en comprendre les conséquences.

11. Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d'avoir de bonnes idées vous-même. C'est même préférable, parfois.

De manière surprenante, vous comprendrez vite que si vous êtes parfaitement honnête quant à ce que vous devez aux autres, tout en restant en retrait, on finira par considérer que c'est vous qui avez tout écrit tout seul et que vous restez modeste par humilité. On sait tous comment cela a bien fonctionné pour Linus !

(Quand j'ai présenté cet article à la conférence sur Perl en août 1997, Larry Wall, l'inventeur de Perl, était assis au premier rang. Alors que j'abordai le paragraphe précédent il cria, d'un ton enthousiaste et fervent:

NdT Larry se moquait gentiment de lui-même; il fréquente des groupes chrétiens qui font des réunions assez pittoresques.
``Oui, dis-le leur, mon frère !'', déclenchant un rire généralisé. Tout le monde dans l'assistance savait comment cela avait bien fonctionné pour l'inventeur de Perl, également.)

Après quelques semaines de travail sur le projet dans cet esprit-là, je commençai à être félicité par des gens qui n'étaient pas mes utilisateurs, mais qui avaient entendu parler du projet. J'ai archivé certains de ces courriers; je les consulterai de nouveau si un jour je me demande avec angoisse si ma vie a été utile à quelque chose :-).

Mais on doit retenir deux autres leçons essentielles, apolitiques, valables pour toutes sortes de conceptions de procédés nouveaux.

12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise.

J'avais tenté de résoudre le mauvais problème en m'acharnant à développer popclient comme un MTA/MDA combinés, m'encombrant d'un tas de modes de distribution exotiques en local. Il fallait repenser la conception de fetchmail du tout au tout, se contenter d'en faire un MTA, un maillon de la chaîne du courrier géré par SMTP sur l'Internet.

Quand vous vous heurtez à un mur au cours du développement d'un projet -- quand vous avez du mal à réfléchir au-delà de la prochaine génération de corrections -- c'est souvent le bon moment pour vous demander, non pas si vous apportez la bonne réponse, mais plutôt si vous posez la bonne question. Il se peut qu'il faille recadrer le problème.

Je le recadrai. Clairement, il me fallait maintenant (1) bidouiller pour ajouter la possibilité de faire suivre le courrier vers le port SMTP dans le pilote générique, (2) en faire le mode par défaut, et (3), finalement, abandonner tous les autres modes de livraison, en particulier les options de livraison dans un fichier ou sur la sortie standard.

J'ai eu des scrupules à franchir la troisième étape pendant un moment, craignant le courroux de mes utilisateurs fidèles, utilisant les autres modes de distribution. En théorie, il leur suffisait de mettre en place des fichiers .forward ou leur équivalent dans un autre système que sendmail pour obtenir exactement les mêmes effets. Dans la pratique, il se pouvait que la transition soit difficile.

Mais quand je le fis, finalement, les avantages furent énormes. Les parties les plus alambiquées du code propre au pilote disparurent. La configuration devenait simplissime -- plus de baratin sur la manière de gérer le MDA et la boîte aux lettres de l'utilisateur, plus d'ennuis quant à savoir si le système d'exploitation sous-jacent permettait de verrouiller des fichiers.

Il faut également noter que l'unique manière de perdre son courrier disparut par la même occasion. Si vous demandiez la distribution du courrier vers un fichier et que le disque était plein, votre courrier était perdu. Cela ne peut pas se produire en faisant suivre le courrier vers le port SMTP, parce que la machine distante ne vous dira pas que tout va bien si elle ne peut effectivement distribuer le message, ou tout du moins le mettre de côté pour plus tard.

De plus, les performances de mon programme s'en trouvaient améliorées (mais pas au point de le remarquer au cours d'une seule session). Un autre bénéfice non négligeable de ce changement de cap fut la simplification drastique de la documentation (la page de man).

Plus tard, il me fallut revenir à un mode de distribution (MDA) en local spécifié par l'utilisateur, de manière à me permettre de gérer certaines situations obscures liées au SLIP dynamique. Mais j'ai trouvé une façon de faire bien plus simple.

La morale ? N'hésitez pas à jeter aux orties des fonctionnalités dépassées quand vous le pouvez sans perdre en efficacité. Antoine de Saint-Exupéry (qui, lorsqu'il n'écrivait pas des classiques pour enfants, pilotait et construisait des avions), a dit:

13. ``La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.''

C'est quand votre code devient meilleur et plus simple, que vous savez qu'il est bon. Et au passage, la conception de fetchmail développa sa propre identité, différente de son ancêtre popclient.

Le temps était venu pour un changement de nom. La nouvelle conception du nouveau programme ressemblait beaucoup plus à une réplique de sendmail qu'à l'ancien popclient; tous deux sont des MTAs, mais alors que sendmail envoie puis distribue, le nouveau popclient récupère avant de distribuer. Deux mois après le démarrage du projet, j'en changeai le nom en fetchmail.


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