Vendredi 23 août 2019

Cher Journal,

C'est vendredi. Béni soit le vendredi : c'est le début de fin de semaine. :)

Un coup d'œil rapide à l'entrée de journal de ce mercredi depuis mon lecteur de flux RSS Newsboat 2.13 me révèle que la piste audio, dans cette situation, n'est pas directement accessible via ce lecteur. Une solution pourrait consister à utiliser le même mécanisme que pour les images.

Une autre pourrait consister à me renseigner sur ce que sont les podcasts : apparemment le paquet newsboat fournit, en plus de la commande newsboat, une commande podboat capable de récupérer ce genre de données dans une file d'attente. À en juger par l'article anglais de l'encyclopédie sur le format Atom, le manque de support natif des enclosures utilisées pour signaler ces contenus multimédia a été un frein à l'adoption du format. Donc ce n'est peut-être pas la meilleur approche dans ce cas précis.

Pour en revenir au repérage des pistes audio en utilisant la même méthode que pour les images, un coup d'œil rapide au code source de Newsboat tel que fourni dans Debian Sid à ce jour, merci apt source newsboat, me conduit à regarder le contenu du fichier src/htmlrenderer.cpp. Mince, c'est du C++ ! Ça va probablement être plus compliqué que prévu. D'un autre côté, personne n'a dit que rendre du code HTML était simple.

À priori, le rendu des images est traité autour d'une variable IMG, ou est-ce une sorte d'enum avec un formalisme d'espace de nom htmltag ? Ça fait bientôt dix ans depuis ma dernière confrontation avec du C++, mes souvenirs commencent à se dissiper. Un coup d'œil curieux au fichier d'en-tête include/htmlrender.h me révèlera que c'est effectivement un enum class htmltag {...}. Bref, des traces de htmltag::IMG sont présentes un peu partout dans le fichier, et marquent le point de départ de chaque traitement afférent aux images.

L'occurrence numéro zéro apparait dans l'initialisation d'un dictionnaire tags, stockant les descripteurs de chaque balise HTML connue du lecteur de flux :

htmlrenderer::htmlrenderer(bool raw)
	: raw_(raw)
{
	tags["a"] = htmltag::A;
// [...]
	tags["ituneshack"] = htmltag::ITUNESHACK;
	tags["img"] = htmltag::IMG;
	tags["blockquote"] = htmltag::BLOCKQUOTE;
	tags["aside"] = htmltag::BLOCKQUOTE;
// [...]
	tags["td"] = htmltag::TD;
}

La première occurrence à lieu dans une fonction render, qui va éplucher les différents composants possibles et normalisés du marqueur HTML <img>, notamment le champ src, qui indique la source où récupérer l'image.

case htmltag::IMG: {
	std::string imgurl;
	std::string imgtitle;
	try {
		imgurl = xpp.get_attribute_value("src");
	} catch (const std::invalid_argument&) {
		LOG(level::WARN,
			"htmlrenderer::render: found "
			"img "
			"tag with no src attribute");
		imgurl = "";
	}

Beaucoup de code sert ensuite à traiter tout un tas de petits cas particuliers moins fréquents, ou alors fréquents mais pas utilisé directement par des êtres humains peut-être. La compréhension de la cuisine qui y a lieu me manque. La fin de la section de code s'occupe du rendu dans le terminal proprement dit, affichant au choix [image N], ou bien si un titre est présent [image N titre], ce qui me fait penser que ce serait bien de renseigner ce champ dans les metadonnées de mes images au passage :

		if (imgtitle != "") {
			curline.append(strprintf::fmt(
				"[%s %u: %s]",
				_("image"),
				link_num,
				imgtitle));
		} else {
			curline.append(strprintf::fmt(
				"[%s %u]",
				_("image"),
				link_num));
		}
		image_count++;
	}
} break;

La deuxième occurrence traite de la balise fermante </img>, toujours dans la fonction render, fonction qui fait plus de 700 lignes. Le code correspondant à cette dernière occurrence consiste essentiellement à ne rien faire, comme suit :

case htmltag::EMBED:
case htmltag::BR:
case htmltag::ITUNESHACK:
case htmltag::IMG:
case htmltag::HR:
	// ignore closing tags
	break;

Et c'est à peu près tout. Le code d'un éventuel htmltag::AUDIO pourrait presque être copié et collé à partir de cette base, tout en pensant à aller ajouter l'entrée dans l'énumération htmltag du fichier d'en-tête. Quelques points restent passés sous silence, mais ça vaudrait le coup par exemple de regarder comment est implémenté la liste des URL répertoriées à la fin de l'article de flux.

Question : quel poids ajoute le paradigme orienté objet au code de Newsboat, sachant la complexité intrinsèque du format HTML, et ce malgré les pans entiers du format qui restent non traités par ce lecteur de flux RSS, sommes toutes relativement simple ?

	Name	Last modified	Size
	Parent Directory		-