Résumé

  • Le RFC 910 relate une réunion tenue chez BBN les 23 et 24 juillet 1984. BBN y présentait Diamond, déjà mis en œuvre sur la station Jericho, capable d'échanger des documents mêlant texte, images, voix, graphiques et tableurs.
  • Dans l'objet tableur de Diamond, les données voyageaient avec leur modèle. Un lecteur complet pouvait essayer d'autres valeurs ; un lecteur minimal pouvait afficher les cellules sans interpréter les formules. Le groupe cherchait aussi à transmettre l'intention de présentation de l'auteur à des écrans et imprimantes très différents.

Un diagramme qui monte promet volontiers un avenir radieux. Changez une hypothèse cachée dans sa grille, et la promesse peut tousser. La différence entre recevoir l'image d'un graphique et recevoir le calcul qui l'a produit est énorme. En juillet 1984, les participants d'une réunion sur le courrier multimédia voulaient placer ce calcul dans le message lui-même. L'enveloppe électronique transportait une question que le lecteur pourrait poser à nouveau.

Les notes de Harry Forsdick, publiées dans le RFC 910, réunissent les travaux de BBN, ISI, SRI et Linkabit. BBN annonçait une première réalisation complète de Diamond sur sa station Jericho. Le système échangeait des documents composés de texte, graphiques, images, voix et tableurs avec graphiques. ISI développait une interface sur Xerox 1108 et disposait déjà d'un module de traitement des messages sous TOPS-20 avec conversion vers le courrier SMTP ordinaire. SRI décrivait sur Sun un gestionnaire de courrier, un éditeur de structures et un module de transport couvrant alors texte, voix et graphiques. Les laboratoires apportaient des pièces différentes d'un même puzzle.

Le tableur de Diamond avait une propriété remarquable. L'objet pouvait contenir nombres, étiquettes, dates et formules ; il transmettait aussi le modèle qui lie ces éléments. Chez le lecteur, un programme capable de le comprendre pouvait modifier des données et observer l'effet sur les conclusions proposées par l'auteur. Selon le logiciel, le même ensemble pouvait apparaître comme tableau, courbe, nuage de points, diagramme à barres ou camembert. Voilà un courrier qui vous livre le graphique et laisse la porte ouverte pour contester la pente.

La réunion prévoyait aussi une version sans acrobaties. Un programme minimal pouvait laisser les formules de côté et présenter les valeurs des cellules. Ce n'était pas un échec du transport : les machines destinataires n'avaient pas toutes la même puissance ni les mêmes programmes. L'auteur pouvait envoyer une structure riche ; le lecteur recevait la partie que son logiciel savait traiter. Le document envisageait qu'un programme étranger à Diamond, face à un tableur inconnu, aboutisse probablement au débogueur. Ce risque de compatibilité donnait du prix à la lecture graduée, du tableau simple à l'exploration du modèle.

La question du tableur conduisait à celle de la page. Un écran bitmap, une fenêtre étroite et une imprimante papier ne partagent ni dimensions, ni résolution, ni polices. Les participants souhaitaient préserver l'intention de l'auteur — regroupement des objets, titres, emphase, relations entre texte et figure — tout en laissant le dispositif du destinataire fixer la présentation finale. Le protocole devait transporter les liens entre éléments sans transformer chaque document en page rigide calculée pour le bureau de l'expéditeur. Cette représentation restait un travail à spécifier, avec une échéance inscrite dans les notes.

Les bases avaient été posées plus tôt. Le RFC 759 de Jon Postel décrivait le protocole de messages et ses modules de traitement ; le RFC 767 proposait une structure pour les documents multimédias. La réunion de 1984 abordait les difficultés de fabrication : quelle forme graphique employer avant qu'une norme plus générale existe, comment faire parler des stations différentes, comment convertir un message riche vers le courrier textuel. Pour les graphiques, les participants retinrent provisoirement le format de Diamond sous le nom MMGraphics1.

Les dates donnent la mesure de l'expérience. Le groupe voulait passer à une syntaxe révisée avant le 1er octobre 1984 et préparait un nouvel essai pour janvier 1985, avec texte, graphiques, images et voix. BBN attendait entre 100 et 200 utilisateurs du banc d'essai ADDCOMPE au cours de l'année suivante. C'était une prévision, au milieu de programmes en cours de construction. Le tableur présenté chez BBN montrait déjà ce que pouvait porter un message ; une conversation régulière entre tous les laboratoires exigeait encore du travail.

Aujourd'hui, on peut recevoir un tableau comme une image figée ou comme un objet sur lequel on raisonne. En 1984, cette distinction tenait déjà toute seule dans une salle de réunion. Envoyer les formules avec les chiffres permettait au destinataire de répondre au graphique autrement qu'en hochant la tête. Le courrier transportait un désaccord possible, soigneusement rangé dans les cellules.