Y compris ceux qui utilisent un plugin.xml et pas un paquet.xml
Indépendamment du fait qu’on pourrait optimiser le chargement des infos des plugins (refont globale du fonctionnement de SVP), il me semble que dans la mesure où les fichiers plugin.xml ne sont plus lu par spip depuis la 4.0 et que spip 3.2 est « en fin de vie » depuis 2023, il serait pertinent de supprimer tout les plugins en plugin.xml.
En première approche, cela représenterait 15 % des plugins décrits dans ce fichier, ce qui n’est pas négligeable
C’est une autre problématique. Moi je parle de refuser plugin.xml tout court, tag ou pas tag.
Le problème de garder uniquement le dernier tag, c’est que tu bloque les mise à jour si tu a 2 branches d’un même plugin (par ex une branche x pour spip 4 et x+1 pour spip 5). A la rigueur on pourrait garder uniquement juste le dernier y de chaque x, mais ca implique de changer de x si on augmente la branche minimal de compatibilité SPIP d’un plugin (sinon impossible de mettre à jour sur des spip anciens), ce qui n’est pas toujours la pratique (notamment récement lorsqu’on a supprimé les compat spip < 4.1).
Mais ca ferait des economies oui. A la rigueur on pourrait imaginer d’avoir un plusierus versions du principal.xml avec une granularité plus ou moins fine
principal_full tel qu’actuellement
principal avec les paquet.xml mais pas les plugin.xml (aka on assume de plus supporté les très très vieux plugins)
principal-y.xml : par plugin, on garde tous les x.y, mais pas tous les x.y.z (seulement celui avec z le plus fort)
principal-x.xml, par plugin, on garde tous les x, mais pas tous les x.y (seulement celui avec y le plus fort) → ca pourrait être ce qu’on configure par défaut en SPIP 5, si on rigoureux et qu’on ne s’autoriser à supprimer une compatibilité avec un spip ancien en se contentant d’un changement de y que si on garde encore la compat avec tous les spip maintenus
principal-lastett.xml, par plugin, on garde uniquement la dernière version, utile uniquement pour les gens qui maitrisent très bien leur SPIP, et le mettent à jour toujours vers la dernière version.
Mais ca devient vite une usine à gaz/risque de confusion etc. Donc je ne suis pas sur que cela en vaille la peine.
A la rigueur on pourrait opter pour cela
principal-y.xml : par plugin, on garde tous les x.y, mais pas tous les x.y.z (seulement celui avec z le plus fort)
Ce qui serait un bon compromis simplicité de compréhension / legerté du fichier (même si c’est rare d’avoir beaucoup de z sur un plugin)
Pour rappel les 3.2 peuvent aussi lire les paquet.xml, donc on ne coupe pas tout
Depuis 2 ans le bases local des plugins ont eu le temps de se mettre à jour, donc ils ont deja les infos sur les plugin.xml existant → on ne leur enlève rien
Decouper en morceau ne réglerait pas tellement le problème parce qu’il faudrait une intervention manuelle des webmestre pour choisir le bon depot à suivre.
Après on peut se dire que cela fait parti des choses qu’on met en place en juillet, en meme temps que la 5.0
Il y a un gain majeur en enlevant les balises traductions
Un gain en enlevant plugin.xml
Des gains plus mineures sur le reste.
À noter que le fichier XML résultant n’est pas valide pour différentes raisons (pas de balise unique en racine, échappements html sans DTD…), et du coup c’est impossible à traiter avec des outils standards, (surtout pour avoir ensuite la même sortie…)
Si on enlève les 133 archives (sur 1244 archives restants) qui ne sont pas au moins compatibles avec SPIP 3.2 (ou 4.x évidemment), alors on arrive à 1.9M
Du coup pour rien changer chez les gens, celui avec l’URL communiquée partout pourrait être réduit comme tu l’expliques, de 9 à 2 c’est énorme. Et en générer un autre genre « archives.full.xml » spécialement destiné à plugins.spip/contrib.spip (dont on sait qu’ils savent lire le gros fichier), pour rien casser à toutes les infos présentées dans les sites ?
C’est une solution pour plugins.spip.net oui d’avoir des archives.full.xml a priori. Mais bon, c’est pas « juste » ça… ça veut dire adapter les pages tel que Dépôts - Plugins SPIP
Et sinon autre élément de comparaison, en repartant des 1244 archives de paquet.xml nettoyées, et en ne conservant que les plugins compatibles SPIP 4.4 on obtient
À noter que le fichier XML résultant n’est pas valide pour différentes raisons (pas de balise unique en racine, échappements html sans DTD…), et du coup c’est impossible à traiter avec des outils standards, (surtout pour avoir ensuite la même sortie…)
il ne l’était pas avant deja non ?
Tout tes tests tu les a fait en modifiant en local le generateur, ou bien tu as éditer le fichier produit avec un éditeur xml ?
Je n’ai pas dit le contraire. C’est historiquement comme ça.
Et non je n’ai pas touché le débardeur pour le moment, j’ai utilisé une IA pour générer des scripts PHP absolument barbares rapidement pour nettoyer ce archives.xml pour voir les gains qu’on peut obtenir. (parce que justement, tu peux pas utiliser les outils XML fournis par PHP (ni de python d’ailleurs) directement… ç’eut été trop simple… Ce qui veut dire aussi que potentiellement il peut y avoir le même problème dans le débardeur pour nettoyer (les balises superflues de paquet.xml), je n’ai pas trop regardé encore avec quoi il lit ces XML (s’il le fait) ;
archives.full.xml n’a pas les plugin.xml et paquet.xml est réécrit (plus court, mais sans modification)
archives.thin.xml n’a pas <traductions> en plus, ni certaines balises de paquet.xml…
Les 3 fonctionnent dans SVP a priori, ce qui est une bonne chose…
Bref, il faudra que je vérifie, mais il semble tout à l’heure dans les trucs un peu rapides, que la suppression de <traductions> avait du supprimer un peu plus d’éléments que prévus… ou alors quelque chose m’échappe…
Bon, trouvé pourquoi le premier script d’analyse rapide avait échoué… ça plantait sur un cas particulier à partir de la ligne 76000 du XML généré, autant dire que c’était pas évident à voir… d’autant que ça conservait bien le bon nombre de balises <archives> bref…
Du coup, après correction il me dit maintenant
7,1M en enlevant les <traductions>
Ce qui correspond mieux à ce qu’on a observé…
Et ce qui est finalement peu comme amélioration…
