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".

Une barre de navigation toujours visible

Un nanoblogger,Raimar Sandner a écrit un petit tutoriel (en anglais) sur l'art et la manière de faire en sorte que la barre de navigation latérale apparaisse sur toutes les pages et non pas seulement sur la page d'accueil. Évidemment, cela imposera une mise à jour forcée totale à chaque fois.

Bloguer par mail avec NanoBlogger

Foogitiff vient de sortir un billet sur l'art et la manière de poster un billet par mail, sur son serveur hébergeant un blog sous NanoBlogger.

Nouvelle release de NanoBlogger

La version 3.4.2 de NanoBlogger vient de sortir ! Elle n'apporte pas de nouvelle fonctionnalité mais des correctifs de bugs concernant la gestion des archives et les liens de syndication. Voici le changelog :

2010-02-15 19:07  n1xt3r

	* ChangeLog, default/templates/main_index.htm, nb, plugins/atom.sh,
	  plugins/rss2.sh, plugins/weblog_links.sh: - Fix: wrong logic
	  found in load_plugins() loop, could cause loop to exit before
	  completion.
	  - Improves integration of feed links.

2010-02-15 03:18  n1xt3r

	* default/blog.conf, docs/nanoblogger.html, plugins/atom.sh,
	  plugins/page/feed_links.sh, plugins/rss2.sh: Cleans up logic for
	  toggling category based syndication.

2010-02-15 01:14  n1xt3r

	* default/templates/archive_index.htm,
	  default/templates/year_archive.htm, docs/nanoblogger.html,
	  nb.conf, plugins/archive/master_index.sh,
	  plugins/entry/format/autobr.sh,
	  plugins/entry/format/autotag-br.sh, plugins/page/feed_links.sh,
	  plugins/weblog_status.sh: Fix: missing syndication links in
	  archives (Charles Curley).

2010-02-14 20:42  n1xt3r

	* lib/tools.sh, plugins/atom.sh, plugins/entry/format/autobr.sh,
	  plugins/entry/format/markdown.sh, plugins/entry/format/raw.sh,
	  plugins/rss2.sh: - Corrects several plugins which wrongly
	  utilized NB_EntryBody over NB_MetaBody.
	  - Repackages with the original and much cleaner shortcode plugin
	  implementation.

2010-02-13 03:51  n1xt3r

	* lib/tools.sh, plugins/entry/mod/base_url.sh,
	  plugins/entry/mod/moods.sh: Activates shortcode plugins for both
	  entries and pages.

2010-02-13 02:54  n1xt3r

	* lib/tools.sh: Fix: Addresses issue where entry plugin data was
	  not being properly retained by
	  NB_EntryBody.

Pour l'instant, il n'y a rien de changé en ce qui concerne le package NB-extra. Mais il va falloir mettre la traduction du manuel à jour...

Pour rappel: la version courante de NanoBlogger se compose de deux packages :
1. nanoblogger 3.4.2
2. nanoblogger-extra 3.4
Le package "nanoblogger-extra 3.4" comprend des fonctionnalités secondaires comme des plugins, des traductions ou des feuilles de style.

Appel à développeurs

Après 187 jours de calme plat, Kevin Wood vient de se remettre au code. Et il a même mis à jour le site officiel de Nanoblogger, en souffrance depuis le 25 juillet dernier... Dans son dernier billet , il lance un appel aux bonne volontés : deux développeurs (ou plus) sont invités à se joindre au projet. La copie de ce billet ci-après:

In all seriousness, I'm looking for two or more people to take on developer roles. Specifically people who have skills in programming and debugging shell scripts. Even if writing code isn't your cup of joe, just helping patch and push new releases out would be highly appreciated! I have a backlog of bugs that need fixing and can't seem to find the time to sit down and start widdling away at them. So, anybody out there interested?