Summary

  • Prospero permettait aux utilisateurs et aux responsables de créer des vues d’annuaire sur des fichiers et des index distants, sans déplacer ni interpréter les données.
  • Le rapport de 1994 décrit ses liens avec Archie et Gopher, ainsi que des intégrations envisagées avec WAIS et le Web ; en 2005, un RFC indique que le protocole n’a pas été largement déployé.

Un répertoire pouvait refléter un besoin

Dans un système de fichiers classique, le répertoire semble appartenir à la machine qui stocke les documents. Prospero posait une autre question : une personne pouvait-elle construire son propre classement à partir de ressources dispersées, sans les copier dans une archive centrale ?

Au début des années 1990, l’Internet proposait plusieurs portes d’entrée. Archie indexait les noms de fichiers de dépôts FTP. Gopher organisait la navigation en menus. WAIS recherchait dans des bases textuelles, tandis que le Web naissant reliait des documents par hypertexte. Ces outils avaient des fonctions distinctes. Trouver un fichier ne signifiait pas qu’il apparaissait dans le classement quotidien d’un chercheur.

Le modèle de système virtuel de Prospero ajoutait une couche d’organisation. Un serveur pouvait publier certaines parties de son propre système de fichiers ou donner accès à des informations issues d’une autre base. Les utilisateurs et les administrateurs pouvaient composer des vues adaptées à leurs besoins. Les entrées renvoyaient aux ressources ; elles ne les réunissaient pas matériellement. Un chercheur pouvait bâtir un parcours cohérent entre plusieurs institutions sans devenir propriétaire de leurs fichiers.

Organiser n’était ni indexer ni transférer

Prospero ne remplaçait pas Archie. Archie constituait une base de noms et d’emplacements de fichiers FTP ; Prospero pouvait exposer cette base au sein d’un répertoire plus vaste. Il ne se confondait pas non plus avec Gopher. Le rapport de 1994 décrit une passerelle qui pouvait traiter des serveurs Gopher comme des bases de données et les combiner à d’autres sources.

Cette intégration avait une limite revendiquée. Prospero n’interprétait pas les données qu’il organisait. Il pouvait contribuer à leur récupération, mais l’affichage et l’usage relevaient de l’application du lecteur. Il ne possédait pas son propre protocole de transfert de fichiers : FTP, NFS, AFS ou Gopher pouvaient assurer l’accès, et Telnet les services nécessitant une connexion interactive. Le répertoire aidait à localiser et à choisir une méthode ; il ne garantissait ni la fraîcheur du document, ni l’autorisation d’accès, ni son utilité.

La distinction était féconde, mais elle plaçait les difficultés aux frontières. Un lien pouvait survivre à son objet. Un serveur distant pouvait refuser une requête. Le client devait encore savoir utiliser le mécanisme renvoyé et présenter le résultat.

Une carte, avec des permissions

Les requêtes d’annuaire de Prospero s’appuyaient sur UDP et sur une couche de livraison fiable propre au projet. Le rapport décrit aussi des contrôles d’accès aux objets, aux répertoires et aux index. Plusieurs mécanismes d’authentification étaient proposés, du simple certificat d’identité déclaré par le client jusqu’à Kerberos version 5. Une vue virtuelle n’était donc pas nécessairement publique : son responsable pouvait limiter qui la consultait.

L’URL prospero:// rendait visible cette séparation. Elle désignait un objet dont le nom, propre à l’hôte, était interprété par le serveur Prospero. Celui-ci pouvait indiquer une autre méthode d’accès, éventuellement représentée par une URL distincte. Le nom ne prouvait pas à lui seul que la ressource existait ou qu’elle était accessible. Même une barre oblique ne garantissait pas une hiérarchie : c’était le serveur qui définissait l’objet.

La métaphore de la carte est plus juste que celle d’un entrepôt. Une carte relie des lieux et propose un chemin ; elle ne possède pas les lieux et ne maintient pas les routes ouvertes. Comme éclairage éditorial — et non comme preuve sur les intentions des concepteurs — les notes de Heng Lu sur les annuaires et l’autorité distribuée invitent à distinguer la description d’une ressource du contrôle exercé sur elle.

Une architecture ambitieuse, une adoption modeste

Le rapport sur la recherche d’information en réseau, publié en 1994, estimait à environ 50 le nombre de serveurs Prospero. Les données sur serveurs et clients avaient été actualisées en novembre 1993. Ce chiffre, fourni par le projet à une date donnée, ne mesure ni les utilisateurs uniques ni la durée d’activité des répertoires. Le même rapport présentait les connexions à Archie et Gopher, tout en décrivant les index WAIS et les documents Web comme des développements à venir.

En 2005, le RFC 4157 a conservé le schéma d’URI tout en classant le document comme historique. Il précise que le protocole n’a pas été largement implémenté et que presque aucun serveur Prospero n’était encore en service. Cette évaluation n’annule pas l’expérience architecturale ; elle en borne la portée. Prospero a rendu concrète l’idée d’organiser des ressources distribuées, sans devenir une couche d’annuaire largement installée.

La difficulté dépassait le code. Une carte personnelle n’avait de valeur que si les responsables publiaient des vues utiles, si les clients comprenaient le même espace de noms, si les passerelles restaient à jour et si les lecteurs acceptaient d’apprendre un nouvel outil. Relier des services avec élégance ne suffisait pas à créer une communauté de maintenance.

La question historique tient donc moins à une prétendue invention d’un système ultérieur qu’au choix entre un index global de référence et une pluralité de cartes locales sur des ressources hébergées ailleurs. Prospero a expérimenté la seconde voie. Son empreinte limitée rappelle qu’une bonne séparation entre classement, stockage et récupération ne garantit pas l’adoption d’un écosystème.

Références