Résumé
- Le RFC 984 plaçait l’état durable du courrier dans un dépôt permanent ; plusieurs PC du même utilisateur pouvaient en garder une copie locale et se synchroniser lorsqu’ils retrouvaient le réseau.
- Des descripteurs d’environ 100 octets donnaient aux petits disques un inventaire complet sans stocker tous les corps de message. Le mode différé mettait les actions en attente ; DMSP les exécutait de façon atomique.
Le PC quitte le bureau, peut-être sur la banquette arrière d’une voiture. Les auteurs de PCMAIL imaginaient explicitement ce trajet en mai 1986. Pendant que la machine bouge, où attend le courrier ? David Clark et Mark Lambert lui ont donné un dépôt permanent, assez pour stocker les messages entrants et l’état global de la boîte. Les ordinateurs personnels passeraient de temps à autre ; le courrier, lui, garderait une maison.
Le paradoxe du PC faisait tout le sel du projet. On pouvait en posséder plusieurs, par exemple un au bureau et un autre chez soi. On pouvait aussi les déplacer. Mais ces machines manquaient de mémoire et de disque : le document décrit comme typique moins d’un mégaoctet de mémoire et une disquette d’environ 360 kilooctets. Emporter toute la correspondance n’était pas toujours réaliste. Emporter la table des matières l’était davantage.
PCMAIL séparait ainsi chaque message en un descripteur et un corps. Le descripteur, long d’environ 100 octets quel que soit le texte réel, contenait l’identifiant, la taille, quelques champs d’en-tête utiles et des indicateurs. Le client pouvait conserver tous ces résumés, puis rapatrier les corps au rythme de la place disponible. On savait qu’une lettre existait avant de pouvoir la garder localement. La modestie du résumé faisait tenir le système dans un petit disque.
Les copies locales avaient une dette envers le dépôt global. En mode interactif, quand le réseau restait présent, les changements rejoignaient aussitôt le dépôt et les nouveaux messages arrivaient au client. En mode différé, le PC travaillait seul et empilait ses actions jusqu’à la prochaine connexion. DMSP, le protocole de la proposition, servait à manipuler le courrier et à rapprocher les deux états. Plusieurs PC pouvaient donc suivre le même utilisateur tout en ayant momentanément des souvenirs différents.
Le rattrapage demandait une règle nette. Les opérations DMSP étaient atomiques : réussite entière ou échec entier. Sans accusé de réception explicite, l’opération était considérée comme échouée. Ainsi, une coupure brutale ne devait pas laisser deux histoires contradictoires d’un message supprimé ou envoyé. Le dépôt notait aussi les changements manqués par chaque client. Dans la réalisation décrite, une absence d’une semaine rendait un client inactif ; à son retour, il recevait une remise à zéro et une copie complète de l’état global au lieu d’une longue succession de petites corrections.
La notice du RFC Editor date le texte de mai 1986 et indique son remplacement ultérieur par le RFC 993. Clark et Lambert présentaient un projet préliminaire soumis à discussion. Son idée centrale tient toujours debout dans ses propres termes : le dépôt se souvient, le PC se déplace, le petit résumé ménage le disque, et le protocole tranche ce qui s’est vraiment passé après une panne de liaison. L’ordinateur rentrait chez lui ; la poste ne fermait pas boutique.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance





