Pour un total de 24 253 lignes (+535).

Une grosse recherche peut télécharger des milliers de résultats, et je profite de ces cas là pour tester les fonctionnalités d’export et de re-import des résultats. Généralement ça marche, mais là je suis tombé sur un os. Quelques heures de recherche permirent d’identifier ce que l’analyseur de fichier XML dénonçait comme caractères XML illégaux dans les fichiers RSS générés par Meta-Press.es. Ce qui enduisait l’interpréteur d’erreur était l’absence d’un caractère qui aurait permis de fermer un motif qu’il était bien le seul à voir, et le message d’erreur pointait donc au milieu d’un texte parfaitement valide si on ne commençait à regarder le fichier qu’à partir de l’erreur rapportée. Ces mystérieux caractères illégaux étaient donc cachés un peu plus tôt dans les URL des illustrations de certains articles, par exemple les URL à destination du vigneteur interactif de https://www.journal-ipns.org (PHP Thumbnailer).

Il s’agissait tout simplement de plusieurs éperluètes "nues" dans ces URL, or le seul usage autorisé des '&' dans un fichier XML est celui d’annoncer le début d’une entité XML (c’est à dire de la description d’un caractère à remplacer lors du décodage du fichier). Une éperluète peut par exemple être remplacé l’entité XML & # 2 6 ; (sans les espaces) mais si on fait ça, c’est le vigneteur en face qui ne s’y retrouve plus.

Il fallut donc remplacer les '&' de ces URL par des & amp ; pour que tout le monde soit content.

Ici le problème était que chercher journal-ipns.org dans la liste complète des sources ne donnait aucun résultat. C’était dû au fait que la bibliothèque de fonction ListJS que Meta-Press.es utilise pour paginer cette liste (et qui fourni également une fonctionnalité de recherche) interprétait les schémas du type -untexte comme une négation : ne pas chercher ce qui contient untexte.

Puisque ListJS n’est plus maintenu, Meta-Press.es est désormais équipé de la version Lovasoa de cette bibliothèque, nommée de part le pseudo du mainteneur qui a entre autre corrigé ce bogue.

Lorsqu’aucun fuseau horaire n’était explicitement choisi par un utilisateur (et donc que le fuseau horaire par défaut du navigateur était utilisé), les utilisateurs français ne pouvaient plus programmer de nouvelles recherches automatique durant la période des heures d’été.

Quelques sérieux ajustements dans la fonction qui crée des dates avec fuseau horaire pour Meta-Press.es ont permis de corriger ce problème (il était question de savoir gérer plus de situations, notamment des fuseaux horaires exprimés en heure, en heure avec minutes, ou juste en minutes comme : -120…).

Celui-ci était un bogue (très bien) signalé par un utilisateur. Typique du genre des petits bugs qui n’ont l’air de rien mais qui se mettent complètement en travers du flot d’exécution mis en place pour accueillir les résultats. On aurait pas dû avoir à s’éloigner du simple : ré-applique les filtres à chaque fois que ajoute des résultats sur la page. Mais pour le coup, je m’en suis occupé en même temps que la ré-organisation MVC du code (dont je parle plus bas) et ça a passablement compliqué les choses (et la correction du bug suivant), tout en mettant bien en évidence le besoin de réorganisation.

Pour faire une grosse recherche, c’est facile, il suffit de chercher "europe" dans toutes les sources connues. C’est à peu prêt comme ça que les sources sont testées et ça ramène plus de 10 000 résultats. Meta-Press.es était alors capable d’exporter ces résultats en RSS, en CSV, mais pas en JSON !? Et sans le moindre message d’erreur.

Il semble en effet que Meta-Press.es se heurtait à une limite sur la taille des fichiers générables (via data: URL) fixée à 20MO (ça devrait être 32MO a priori). Dans notre cas, les fichiers RSS et CVS étaient plus petits que leur homologue JSON car ils embarquent moins d’information, perdant notamment le nombre de résultats revendiqués par chaque source.

En diminuant le nombre de caractères de présentation utilisés dans le JSON produit, l’export JSON passait à 19,9MO et avait bien lieu. Ces limites existent et varient au cours du temps et au gré des navigateurs. Une meilleur solution devrait être trouvée rapidement.

Cela pourrait être une fonctionnalité d’export découpé en plusieurs fichiers de 20MO chacun, et une amélioration de l’import, pour être capable de ré-importer une série de fichiers (et pourquoi pas de deviner le type d’un fichier importé en fonction de son extension).

Tant qu’à se pencher sur les exports et les imports, leur code a été globalement amélioré pour fournir plus de réactivité aux utilisateurs et mitiger d’un facteur 15x la perte de performance due à la ré-organisation du code (qui impactait les imports JSON). Il s’agissait là tout simplement de ne ré-ordonner les résultats qu’une fois toutes les 15 sources, et pas à chaque source, car on a pas de temps à perdre quand on import un gros fichier JSON, c’est pas comme si on passait son temps à attendre les résultats de la prochaine source… (comme c’est habituellement le cas)