J'ai lu (en diagonale) la présentation de Gemini et sa FAQ. Ma première impression est que son auteur n'a pas compris le protocole Gopher de la même manière que je le comprend. Voici mon point de vue.
Il existe une rfc 1436 "Informational" dont leurs auteurs on déclarés à l'époque de sa sortie (1993) quelle avait pour but de stabiliser la précédente version de Gopher alors qu'ils publiaient la nouvelle spécification "Gopher+" (disponible sur ce site).
Bien plus tard, en 2005, est sorti la la rfc 4266 portant "The gopher URI Scheme" qui, elle, est en catégorie "Standards Track". Clairement, la rfc 4266 fait bien état du protocole Gopher+ totalement ignoré (ou snobé ?) par le projet Gemini. Il se trouve que bien des lacunes relevées à juste titre par le projet Gemini concernant la première version stabilisée de Gopher telle que décrite dans la rfc 1436 sont comblées avec la seconde version du protocole Gopher dite "Gopher+".
Alors je m'interroge sur la démarche des porteurs du projet Gemini : le lien ci-dessus vient du site de Goerzen (personnalité bien connue du petit monde Gopher) et on trouve aisément cette feuille de route pour Gopher+ un peu partout dans le gopherspace.
Le second volet de mon commentaire concerne les définitions du Web d'une part et celle de la page Web d'autre part.
Ma définition du Web est celle d'un espace sur Internet partagé par des protocoles qui ont tous en commun le fait d'être accessible par une URI (ftp://, gopher://, http://, telnet://, etc). La notion d'URL a été gravée dans le marbre avec la rfc 1738 en 1994 par deux auteurs : T. Berners-Lee, que l'on ne présente plus, et M. McCahill qui était le leader de l'équipe Gopher. On présente souvent le projet du World Wide Web comme rival à celui de Gopher alors que les deux équipes ont toujours collaboré ensemble. Ces deux projets avaient des buts absolument différents et n'empiétaient en rien l'un sur l'autre. Il est navrant de confondre Web et World Wide Web. L'un est la toile que l'on peut parcourir avec l'un des quelconques protocole (ftp, telnet, http, gopher, wais... et j'en oublie) et l'autre une suite de protocoles porté par le W3C.
Concernant la définition de la page Web, on touche le cœur du problème ! D'abord on devrait dire "page de texte encodé en HTML" (plus divers autres encodages). Rien n'interdit de télécharger un fichier Text/html depuis un serveur ftp ou Gopher ! Certes, on peut dire que la grosse nouveauté du format HTML a été l'en-tête apportant tout un tas de renseignements intéressants. Mais Gopher+, apporte également bien des renseignements nécessaires à n'importe lequel des fichiers à télécharger (contrairement à la version première de Gopher).
Enfin, et je crois que c'est le fond du projet Gemini), la définition de "page Web". Je pense qu'on est bien d'accord que le souci principal est le côté "métier du livre" qui n'est pas un métier facile. On ne sait toujours pas bien faire un traitement de texte et seulement un ou deux squattent le marché. De même pour le format PDF. Et là, on voudrait avoir ces deux logiciels en un...
À ce que j'ai compris des fanatiques (le mot n'est pas trop fort !) du protocole Gopher : ils sont nostalgiques des anciens BBS. Alors ils détournent l'usage premier des menus Gopher, qui ne sont strictement qu'une liste ordonnée de liens, en y incluant des lignes de texte débutants par la balise de type "i" (qui est non officielle mais reconnue par "Lynx" qui domine tous les navigateurs Gopher). Ce contournement permet de présenter une "page Web" en mode texte avec des liens mais sans le très honni HTML.
Reste le volet de la sûreté des communications. Un faux problème, à mon avis ! En effet, le protocole Gopher transporte en clair et sans authentification. Mais si on veut brouiller ou authentifier, rien n'interdit d'encapsuler Gopher sous HTTP(S). Déjà, en 1996, la rfc 1945 pour HTTP/1.0 prévoyait le transport d'autres protocoles comme SMTP, NNTP, FTP, Gopher et WAIS. Et c'est toujours le cas dans la section 1.1 de la rfc 2616 pour HTTP/1.1 .
[^] # Re: Gopher
Posté par Denis Bernard . En réponse au journal Gemini et Solid, deux alternatives au Web (qu'il faut qu'on m'explique). Évalué à 6. Dernière modification le 26 novembre 2020 à 02:46.
J'ai lu (en diagonale) la présentation de Gemini et sa FAQ. Ma première impression est que son auteur n'a pas compris le protocole Gopher de la même manière que je le comprend. Voici mon point de vue.
Il existe une rfc 1436 "Informational" dont leurs auteurs on déclarés à l'époque de sa sortie (1993) quelle avait pour but de stabiliser la précédente version de Gopher alors qu'ils publiaient la nouvelle spécification "Gopher+" (disponible sur ce site).
Bien plus tard, en 2005, est sorti la la rfc 4266 portant "The gopher URI Scheme" qui, elle, est en catégorie "Standards Track". Clairement, la rfc 4266 fait bien état du protocole Gopher+ totalement ignoré (ou snobé ?) par le projet Gemini. Il se trouve que bien des lacunes relevées à juste titre par le projet Gemini concernant la première version stabilisée de Gopher telle que décrite dans la rfc 1436 sont comblées avec la seconde version du protocole Gopher dite "Gopher+".
Alors je m'interroge sur la démarche des porteurs du projet Gemini : le lien ci-dessus vient du site de Goerzen (personnalité bien connue du petit monde Gopher) et on trouve aisément cette feuille de route pour Gopher+ un peu partout dans le gopherspace.
Le second volet de mon commentaire concerne les définitions du Web d'une part et celle de la page Web d'autre part.
Ma définition du Web est celle d'un espace sur Internet partagé par des protocoles qui ont tous en commun le fait d'être accessible par une URI (ftp://, gopher://, http://, telnet://, etc). La notion d'URL a été gravée dans le marbre avec la rfc 1738 en 1994 par deux auteurs : T. Berners-Lee, que l'on ne présente plus, et M. McCahill qui était le leader de l'équipe Gopher. On présente souvent le projet du World Wide Web comme rival à celui de Gopher alors que les deux équipes ont toujours collaboré ensemble. Ces deux projets avaient des buts absolument différents et n'empiétaient en rien l'un sur l'autre. Il est navrant de confondre Web et World Wide Web. L'un est la toile que l'on peut parcourir avec l'un des quelconques protocole (ftp, telnet, http, gopher, wais... et j'en oublie) et l'autre une suite de protocoles porté par le W3C.
Concernant la définition de la page Web, on touche le cœur du problème ! D'abord on devrait dire "page de texte encodé en HTML" (plus divers autres encodages). Rien n'interdit de télécharger un fichier Text/html depuis un serveur ftp ou Gopher ! Certes, on peut dire que la grosse nouveauté du format HTML a été l'en-tête apportant tout un tas de renseignements intéressants. Mais Gopher+, apporte également bien des renseignements nécessaires à n'importe lequel des fichiers à télécharger (contrairement à la version première de Gopher).
Enfin, et je crois que c'est le fond du projet Gemini), la définition de "page Web". Je pense qu'on est bien d'accord que le souci principal est le côté "métier du livre" qui n'est pas un métier facile. On ne sait toujours pas bien faire un traitement de texte et seulement un ou deux squattent le marché. De même pour le format PDF. Et là, on voudrait avoir ces deux logiciels en un...
À ce que j'ai compris des fanatiques (le mot n'est pas trop fort !) du protocole Gopher : ils sont nostalgiques des anciens BBS. Alors ils détournent l'usage premier des menus Gopher, qui ne sont strictement qu'une liste ordonnée de liens, en y incluant des lignes de texte débutants par la balise de type "i" (qui est non officielle mais reconnue par "Lynx" qui domine tous les navigateurs Gopher). Ce contournement permet de présenter une "page Web" en mode texte avec des liens mais sans le très honni HTML.
Reste le volet de la sûreté des communications. Un faux problème, à mon avis ! En effet, le protocole Gopher transporte en clair et sans authentification. Mais si on veut brouiller ou authentifier, rien n'interdit d'encapsuler Gopher sous HTTP(S). Déjà, en 1996, la rfc 1945 pour HTTP/1.0 prévoyait le transport d'autres protocoles comme SMTP, NNTP, FTP, Gopher et WAIS. Et c'est toujours le cas dans la section 1.1 de la rfc 2616 pour HTTP/1.1 .