NanoBlogger francophone

Gopher mania

Et de trois... Je parle des Nanobloggers ayant attrapés le virus de ce protocole Internet oublié de tous... sauf des gens ayant un penchant pour l'underground (au sens propre, voir la signification du mot "gopherhole" !). Au commencement était le regretté blog "Druuna", puis celui de ce site. Maintenant, le petit nouveau: "Chicken'z blog" (voir la liste des nanobloggers actifs ci-contre). Trois individus de notre communauté du logiciel de blog Nanoblogger ayant un serveur gopher en regard du monde entier, ce n'est pas rien : les statistiques pifométriques, les plus subjectivement sincères, annoncent moins de 200 serveurs gopher dans le gopherspace ! Le Chicken'z blog, de création récente (et qui mérite une longue visite), parle de la découverte du protocole Gopher et la confection d'un serveur idoine dans l'enthousiasme qui s'en est suivi. Son auteur pointe du doigt l'obsolescence délicieuse du protocole Gopher et semble ne pas être optimiste pour son avenir. C'est oublier les points suivants qui font, bien au contraire, du protocole Gopher un protocole d'avenir :

1. Le protocole HTPP n'a toujours pas fait disparaître le protocole FTP. Or Gopher fait mieux que le protocole FTP anonyme en ce qu'il peut donner une description du fichier à télécharger.
2. Ses fichiers menu (sélecteur n°1) remplacent l'arborescence classique de la forme de répertoires physiques, en arborescence logique. Autrement dit : tous les fichiers téléchargeables peuvent résider dans un répertoire unique, tout en donnant l'impression à l'internaute d'évoluer dans l'arbre d'un système de fichiers. Ce point n'est pas anodin quand on sait que tous les langages de programmation ne peuvent créer des répertoires, sauf à faire une programmation mixée avec du "C" ou des appels à la ligne de commande.
3. Due à l'extrême simplicité des requêtes, le serveur ne peut que connaître l'adresse IP de l'internaute. Au contraire, le protocole HTTP permet d'obtenir (immédiatement) bien plus d'informations comme la version du navigateur Internet (et donc la version de l'OS) ou si la page a déjà été vue auparavant. Il y a une meilleure protection de la vie privée avec le protocole Gopher.
4. N'importe quel programmeur débutant peut écrire un serveur Gopher minimaliste dans un quelconque langage de programmation, quitte à le faire tourner sous xinetd. Il y a donc une émancipation possible face à des poids lourds comme Apache.
5. Gopher concerne aussi bien la délivrance de fichiers pré-existants (comme les pages statiques au format "texte" des phlogs) que la génération dynamique de fichiers, à la CGI.
6. Gopher peut faire la même chose que les moteurs de recherche (comme Google), le sélecteur n°7 étant prévu à cet effet. Mais ça nécessite un serveur plus évolué, fonctionnant en mode dynamique, à la CGI. là aussi, faisable par l'amateur éclairé.

Concernant l'obsolescence, la RFC fondatrice incite à l'expérimentation et envisage des versions futures, à condition de conserver le principe de simplicité de ce protocole. Rien n'interdit moralement (vis-à-vis des initiateurs de Gopher), ni matériellement, d'expérimenter une version moderne et la concrétiser par une nouvelle RFC ! Ainsi pourrait être étudié les points suivant :

1. L'Unicode n'était pas en vigueur autrefois. Il pourrait être imposé pour l'écriture des fichiers "texte" et "menu" (sélecteurs "0" et "1". Cela rendrait le protocole Gopher utilisable dans toutes les langues dont les caractères ne sont pas latins.
2. Concernant les autres sélecteurs: on pourrait les considérer systématiquement comme gérant une même famille de type de fichiers. Par exemple un sélecteur unique pour tous les fichiers images, un pour les fichiers audio-vidéo, un pour les fichiers conteneurs d'archives, un pour les documents imprimables (PDF, PostScript, DVI,...), etc. On pourrait ainsi se servir de l'extension (à la MIME) du fichier pour dire au client, déclaré apte à un sélecteur donné, comment opérer.
3. Unifier l'appellation du fichier menu s'ouvrant par défaut quand le serveur est contacté par un client qui n'a pas mentionné de fichier précis, le pendant du fichier "index.html" du monde HTTP.

Concernant l'abandon du support du protocole Gopher par le navigateur Firefox :

• Il y a un module téléchargeable sur le site de Mozilla issu du projet Overbite. Ce module assure la continuité de Gopher sur Firefox et SeaMonkey. Overbite a aussi quelque chose pour Android et Chrome et un futur est envisagé pour Safari, Opéra et Internet Explorer.
• Depuis la création du site web "gopherproxy.org", le contenu des fichiers en format "texte" est devenu visible par le moteur de recherche Google. Par expérience, Il est même permis de penser qu'une information publiée dans un phlog est mieux référencée vu la facilité du format "texte". Dur, dur pour l'underground !

Non, définitivement non, Gopher n'est pas mort !

"Chicken'z blog" évoque, dans un autre billet, quelque chose qui est connexe aux phlogs, (qui sont les blogs dans le monde Gopher): l'édition en vue d'une sortie direct en format "texte pur". Ce n'est pas aussi trivial que ç'en a l'air; ainsi pour la version Gopher de ce site, il est fait l'emploi du navigateur en mode console "Lynx" avec les options "dump" et "justify" depuis des billets rédigés directement en HTML (format RAW de Nanoblogger). Si l'on veut envisager, aujourd'hui, la rédaction d'un billet pour un phlog (donc en texte pur), le plus rationnel est de passer par un format intermédiaire comme le HTML. Voir aussi le cas des RFC qui ne connaissent que le format "texte" pour leur soumission : il existe une RFC récente (5385) " Version 2.0 Microsoft Word Template for creating Internet Draft and RFC's"; preuve qu'il y a bien pénurie d'une spécification (à la LaTeX ou à la HTML) en ce domaine (et ne parlons pas de groff !). Il pourrait être tenu compte des préconisations sur le style des RFC sur la page Web du RFC-Editor, pour le cahier des charges d'un processeur de texte en format "texte".