Le moteur de ce blog est une abomination sans nom. Il s'agit d'un
programme C, que j'ai écrit il y a sept
ans, qui parse un fichier source XML unique que
j'édite et qui contient toutes les entrées, pour produire les
fichiers HTML statiques rassemblant les entrées de chaque
mois ainsi que celui contenant les 20 dernières entrées et celui
reprenant mes fragments littéraires gratuits ou encore
l'index de toutes les entrées. Le
même programme sert à générer un certain nombre d'autres pages de ce
site Web (mais pas toutes, parce que j'ai un bon nombre de couches de
vieilleries empilées les unes sur les autres 
—
avec au moins trois styles de présentation différents, plus quelques
pages qui sont exceptionnelles pour une raison ou une autre).
Je n'ai pas voulu utiliser un moteur de contenu|blog standard, d'abord parce qu'en 2003 le choix n'était pas terrible, mais aussi parce que je tiens à avoir des pages HTML statiques et pas générées à chaque requête, ou parce que je déteste le PHP, ou simplement parce que je suis control-freak. Je me suis dit qu'avoir mon propre moteur me donnerait plus de flexibilité pour me créer des nouveaux tags dans le source, pour organiser mon contenu comme je le veux, ou ce genre de choses. Enfin, ça c'était la théorie, et ça n'a pas marché du tout.
J'ai écrit le moteur en C pour des raisons d'efficacité : la machine qui fait le traitement était initialement une machine de l'ENS complètement à bout de souffle, et toutes les autres solutions que j'avais regardées (notamment des choses sur Perl) étaient abominablement lentes. Quant à XSLT, sur lequel j'étais parti, il n'était décidément pas adapté (déjà, seule la version 1 existait en 2003, mais le moindre test, comme pour vérifier que les entrées étaient bien numérotées correctement, devenait une insupportable prise de tête).
Mais même en C, l'efficacité est devenue un problème. Mon programme ne génère qu'un fichier mensuel par appel : pour générer tous les 86 fichiers de sortie (84 mois plus trois fichiers particuliers), il faut donc l'appeler 86 fois, et à chaque fois il doit parser complètement le fichier d'entrée qui fait maintenant 5.5Mo. Ça fait l'équivalent de 470Mo de XML à traiter : même si le serveur qui fait le traitement est un peu plus rapide que celui avec lequel j'ai commencé, ça prend presque une minute, que je n'ai pas envie d'attendre à chaque fois que je compile pour vérifier que tout s'affiche bien comme je veux. J'ai adopté la moyenne mesure consistant à recompiler à chaque modification seulement les fichiers des trois derniers mois (plus l'index et le fichier des 20 dernières entrées), et à recompiler une fois par mois (ou quand j'en éprouve le besoin particulièrement) la totalité du HTML, des fois que j'aurais fait des corrections de fautes d'orthographes dans des entrées un peu anciennes. Ce n'est vraiment pas satisfaisant (mais détecter si une entrée ancienne a changé n'est pas facilement possible). Et surtout, ça m'a empêché de créer d'autre « catégorie » que celle des fragments littéraires gratuits (savoir quels fichiers recompiler deviendrait de plus en plus abominable). En l'état actuel du programme, le modifier pour produire plusieurs fichiers en sortie par un seul appel serait d'une difficulté inextricable.
Et je ne parle pas des maux de tête au sujet du fil RDF, qui est une abomination dans une abomination (un autre programme C qui partage une partie du code source du premier) : je sais qu'on m'a demandé mille fois de mettre des heures dedans, et/ou de mettre le début de mes entrées plutôt que juste leur titre, mais avec le programme que j'ai c'est juste trop difficile.
Ajouter à ça que la compilation du programme C moteur de blog lui-même est très lente (il y a un fichier source qui est assez énorme). Donc, même sans compter que toute manipulation de chaînes de caractères en C s'apparente au plaisir de résoudre une équation différentielle à la règle à calcul : ajouter le moindre tag que je pourrais utiliser dans le source est vraiment trop chiant. Du coup, finalement, je fais presque tout à la main (par exemple, les notes en bas d'entrée, elles ne sont pas formatées automatiquement comme elles devraient l'être). Tout ça fait que j'ai envie de tout mettre à la poubelle.
Je viens de passer la journée à me demander ce que je veux utiliser
à la place. Je pense que je m'oriente vers une architecture en Perl,
utilisant
la XML::LibXML
(même si j'ai déjà eu des soucis
avec), et vers une compilation en deux parties, une partie consistant
à insérer les entrées dans une base de données SQL (ce
qui permettra, par exemple, de savoir plus facilement celles qui ont
changé) et la seconde consistant à générer les
fichiers HTML à partir de différents modèles qui font
appel à cette base de données.