Impacts sur l’existant

C’est là que les choses sérieuses commencent ! En effet, si l’on veut arriver à un résultat probant il est indispensable que les informations mises en base de données soient pertinentes, ce qui n’est pas « totalement » le cas actuellement (euphémisme). Le souci majeur est le contenu des fichiers plugin.xml...

Les fichiers plugin.xml

L’un des enjeux majeurs de la modélisation proposée par SVP est de différencier le plugin de ses paquets. Le plugin.xml est donc au centre du problème car aujourd’hui il contient à la fois des informations propres au « plugin » et propres au « paquet ». Je dirais même que le plugin.xml est aujourd’hui plus une description du paquet.

L’idéal aurait été, soit d’avoir deux fichiers xml comme plugin.xml et paquet.xml implémentant les tables de SVP, soit de définir dans le fichier plugin.xml deux blocs distincts ... et .... Je pense que ce n’est pas envisageable aujourd’hui (oui – non ?), il faut donc se résoudre à nettoyer puis contrôler les fichiers actuels.

Je propose donc de modifier les plugin.xml en adoptant les règles suivantes :

1. Assurer la constance et l’unicité des informations des plugins quitte à renommer certains plugins / paquets. Cela concerne donc les balises :
   • <prefix> : a priori aucun problème
   • <nom> : renommer les plugins à rallonge (utiliser le slogan), supprimer le 2, 3.0 en fin de nom en privilégiant la branche et je dirais même supprimer le multi-langues pour le nom car cela ne veut rien dire : “Mes fichiers” n’est jamais connu sous le nom “My files”.
   • <categorie> : systématiser son utilisation
   • <slogan> : systématiser son utilisation en s’inspirant soit du titre, soit de la balise <description>. Peut être multi-langues.
2. Pour les informations du paquet :
   • Créer la branche quand cela est nécessaire <branche> en recommandant d’éviter que la branche porte le nom de la version SPIP mais plutôt 2, 3, 4... (ça correspond en fait à la branche SVN souvent)
   • Vérifier et corriger la balise <necessite> pour SPIP car celle-ci n’est presque jamais correctement définie. En général, elle dit >= SPIP x.y mais jamais < SPIP x.y ce qui est presque l’information la plus importante des deux.
   • Surement d’autres choses.... car SVP aujourd’hui ne collecte que 582 paquets sur les 626 actuellement proposés dans archives.xml (voir la définition de l’égalité de deux paquets)

Aujourd’hui SVP fourni un log des mises à jour qui peut être développé pour préparer les modifications requises. J’ai déjà deux fonctions tordues qui essayent tant bien que mal d’extraire le slogan et le nom des plugin.xml actuels.

Les thèmes

Et oui, les thèmes ont tous le même préfixe ce qui selon la modélisation de SVP les classes tous dans le même plugin. On peut appréhender la relation plugin - thèmes de deux façons donc :

1. Considérer que le fait d’avoir un seul plugin « thèmes » ne pose pas de souci et conserver la structure actuelle : tous les thèmes Z ou autres sont des instances, c’est-à-dire des paquets, du plugin unique. Je ne suis pas convaincu que cette solution tienne la route.
2. Il y a un plugin pour un groupe de thèmes ou un thème au choix, selon ou pas le bon vouloir du développeur. Dans ce cas, le préfixe retrouve son intérêt mais d’un autre coté :
   • SVP doit reconsidérer son test d’égalité de paquets pour les thèmes (pas compliqué)
   • on perd le mécanisme SPIP actuel qui exclue deux plugins de même préfixe. Mais est ce un problème ? Ne pouvons nous pas nous en sortir avec la catégorie qui elle est fixée à "theme" et peut permettre de faire le même test.

Le plugin STEP

L’impact sur le plugin STEP est bien entendu d’intégrer la gestion de la base des paquets offerte par SVP. Comme SVP s’est inspiré fortement des fonctions STEP cela ne devrait pas être trop compliqué surtout si on arrive à garder le maximum d’étanchéité entre les deux plugins. Je crois que beaucoup d’utilisateurs attendent avec impatience un STEP pour faciliter leur travail de mise à jour...

Todo et idées d’amélioration

Le site de consultation des plugins

Il faut bien parler aussi du but ultime de SVP, à savoir, fournir le socle de développement du prototype de SPIP-Contrib.Maintenant, sans vouloir relancer un troll (si si c’est vrai !), je me demande si SVP, en agissant comme un agrégateur, ne serait pas l’occasion de créer un vrai site « plugins.spip.net  » qui se fout de l’emplacement des plugins et de leur documentation mais qui offre l’interface adaptée unique pour rechercher les plugins ?

Et une identité visuelle propre me paraît plus intéressante que celle de SPIP-Contrib... A méditer !

Un annuaire des auteurs de plugins

A rapprocher du site de consultation des plugins, il serait intéressant de pouvoir compter sur un annuaire des contributeurs de plugins afin de modifier dans le plugin.xml les crédits de la balise auteur en vraie référence vers un auteur et sa description. On pourrait d’ailleurs créer aussi la balise crédits pour conserver un champ plus libre d’expression des remerciements.

Alors ce site pourrait-être SPIP-Contrib bien entendu mais aussi le site de consultation des plugins si on choisit une option différente que celle de SPIP-Contrib.

L’outil Smart Paquets

En fait, aucune modification n’est strictement nécessaire pour faire fonctionner SVP. Cependant, comme Smart Paquets génère le fichier archives.xml de la Zone, il paraît intéressant :

1. de rendre cet outil réutilisable sur d’autres dépôts SVN, Git ou manuel (peut-être est-de déjà le cas ?)
2. et de l’utiliser pour vérifier la complétude et l’application des règles sur l’écriture des plugin.xml (créer un log des erreurs en partant du principe que seul un plugin.xml correct autorise la génération du paquet)

Je ne sais pas si il y a aussi un quelconque intérêt à passer cet outil en plugin SPIP ?

De nouveaux dépôts ?

En fait, il pourrait être intéressant de ne pas se limiter à un seul gros dépôt SPIP-Zone maintenant qu’il est aisé de proposer une page de téléchargements regroupant plusieurs dépôts. On pourrait imaginer un dépôt pour les vieux plugins (ça fait un peu mouroir désolé), suivant les versions SPIP, pour les expérimentations... non ?

Et quoi d’autres ?

Surement pleins de choses mais j’ai plus d’idée là... enfin il faut aussi finir la todo de SVP ;-)...