Evolution v2 du plugin Boussole

, par _Eric_

Rappel du fonctionnement de la version v1 actuelle

Le plugin Boussole v1 est basé sur les principes suivants :

  • une boussole est définie par un fichier XML, la liste des logos et les items de langue des noms, slogans et descriptions des sites et groupes concernés ;
  • le fichier XML est lu une fois par jour par le plugin et ses informations sont mises à jour dans la base de données à l’exception des traductions et des logos bien entendu ;
  • le fichier XML de la boussole SPIP est chargé automatiquement à l’activation du plugin Boussole. Ce fichier fait partie du squelette boussole.spip.org de la galaxie SPIP ;
  • les items de langue de la boussole SPIP ainsi que ses logos font partie du plugin Boussole ;
  • les sites d’une boussole sont regroupés selon cinq groupes définis une fois pour toute pour toutes les boussoles mais dont l’utilisation est optionnelle et personnalisable ;
  • tout site souhaitant afficher la boussole SPIP doit activer le plugin Boussole.

On note d’emblée qu’il y a, dans le plugin Boussole v1, un mélange entre fonctions de service généralistes et contenu de la boussole SPIP à l’origine des problèmes discutés ci-après.

Problèmes posés par la version v1 actuelle

Les problèmes de cette version v1 sont principalement visibles lors des mises à jour des boussoles, et particulièrement, de leurs items de langue et de leurs logos.

En effet, étudions un par un les différents cas de mise à jour d’une boussole -par exemple, la boussole SPIP-, à savoir :

  1. modification de l’url ou du statut d’activité d’un site de la boussole,
  2. ajout d’un site dans la boussole,
  3. modification d’une information traduite ou du logo d’un site déjà présent dans la boussole,
  4. et suppression d’un site de la boussole.

1- Modification d’une URL ou de l’activité d’un site

Ces deux informations sont contenues exclusivement dans le fichier XML de description de la boussole. Lors de la mise à jour quotidienne de la boussole via le CRON SPIP, ces informations sont relues et mises à jour en bdd.

En outre, comme le fichier XML n’est pas inclus dans le « plugin » Boussole mais disponible dans le « squelette » boussole.spip.org, chaque site utilisant la boussole SPIP sera mis à jour sans souci dés l’instant où le site boussole.spip.org est mis à jour. Ce fonctionnement est donc optimal car il ne nécessite la mise à jour que d’un seul site.

2- Ajout d’un site

L’ajout d’un site demande en premier lieu de modifier le fichier XML de la boussole pour y intégrer une balise <site alias="xxx" src="http://xxx" actif="oui" />. Comme pour le cas 1, tous les sites utilisant la boussole SPIP vont voir leur base de données mise à jour avec ce site.

Pour autant, si on s’arrête là, le site n’a ni logo ni aucune traduction disponible. Il faut donc ajouter les logos dans le plugin Boussole (emplacement images/boussole/) et les traductions comme des items de langue dans les modules lang/boussole_xx.php.

Mais à partir de ce moment, il faut que tous les sites utilisant la boussole SPIP mettent à jour le plugin lui-même afin de récupérer les traductions et le logo. Ce fonctionnement est pénible et l’on risque de voir longtemps des boussoles avec un nom ou un slogan réduit à celui de l’item de langue associé.

3- Modification d’une information traduite ou du logo

Cette modification est similaire au cas 2 pour ce qui est des traductions et du logo. Il faudra donc mettre à jour le plugin Boussole sur tous les sites utilisateur.

4- Suppression d’un site

Que ce soit en passant le site en inactif dans le fichier XML de la boussole ou en supprimant complètement la balise, cette modification sera prise en compte par tous les sites utilisateur lors de la mise à jour quotidienne pour autant que le site boussole.spip.org ait été upgradé. Comme la base de données ne fera plus référence à ce site, les affichages seront donc corrects sans autre intervention.

Néanmoins pour être complet lors d’une suppression, les traductions et le logo devraient aussi être supprimées du plugin Boussole. Ce cas est un peu bancal car les sites fonctionneront correctement avec des versions du plugin Boussole obsolètes.

Nouvelles exigences pour une v2

L’objectif de cette version v2 est donc de simplifier les mises à jour d’une boussole pour les sites utilisateur en ne les obligeant plus à upgrader leur plugin Boussole.

On peut exprimer cet objectif en plusieurs exigences plus techniques :

  • EX1 : il faut séparer les composants d’une boussole -XML, logo et traductions- du plugin affichant la dite boussole.
  • EX2 : il faut un mécanisme de mise à jour d’une boussole sur chaque site utilisateur qui permette de récupérer toutes les informations -y compris les traductions et les logos- d’une façon automatique sans avoir à mettre à jour le plugin Boussole.
  • EX3 : il faut donc un « serveur » qui fournisse sur demande les informations complètes sur une boussole.
  • EX4 : il faut conserver la possibilité pour une boussole d’avoir ses noms, slogans et descriptions traduits via le site Traduire SPIP.
  • EX5 : il faut limiter les échanges entre le « serveur » et les sites utilisateur.
  • EX6 : il faut assurer une compatibilité ascendante en faisant en sorte que les sites utilisateur n’aient qu’une mise à jour de leur plugin Boussole à faire et rien d’autre.
  • EX7 : il faut étendre l’utilisation des groupes en permettant de définir leur liste, leur alias.

Solutions possibles pour répondre aux exigences v2

Les exigences EX1 et EX4 conduisent à scinder le plugin en deux :

  • d’un coté les fonctionnalités de gestion des boussoles dans un plugin,
  • et de l’autre les composants -XML, logos, traductions- de la boussole SPIP proprement dite dans un format qui autoriserait les traductions.

L’exigence EX3 induit la création d’une fonction serveur qui permet de mettre à disposition des sites client les informations d’une boussole (sites, groupes, traductions) ainsi que ses logos. Cette fonction pourrait être à la base d’un nouveau plugin serveur de boussoles.

Néanmoins, le meilleur compromis semble être de regrouper les fonctions serveur et client dans un même plugin dérivé du plugin Boussole actuel et de sortir dans un plugin Boussole SPIP les composants de cette boussole, ce qui répondrait aux exigences EX6 et EX4.

Cependant, il peut être intéressant pour d’autres boussoles personnalisées, d’autoriser une diffusion simple sans passer par un plugin.

Pour répondre à l’exigence EX2, le plugin Boussole actuel doit évoluer pour permettre la mise à jour des boussoles non plus par la lecture d’un XML mais pas la réception des informations via une requête adressée à un serveur (réponse JSON ou XML). En revanche, les logos doivent être accessibles sur ce même serveur dans un espace ouvert à leur lecture à l’instar de SVP et des logos de plugins.

Néanmoins, comme requis par l’exigence EX5, il sera nécessaire de limiter au strict minimum les requêtes au serveur étant donné que le nombre de sites client peut être important. Un mécanisme type md5 devra être ajouté soit à la fonction d’upgrade client actuelle soit à la fonction de réponse du serveur.

Pour l’exigence EX7, il faut pouvoir gérer les alias de groupes quels qu’ils soient.