search

assemblee-virtuelle / archipelago

Fostering interconnections between communities by creating synergies between their platforms
Apache License 2.0
14 stars 6 forks source link

[Minor] (v2.0.0) Upgrade to Semapps middleware v0.7.0 #180

Closed mguihal closed 2 months ago

mguihal commented 2 months ago

Hello,

Je propose cette mise-à-jour de Semapps middleware. J'ai testé le fonctionnement basique et il n'y a pas l'air d'y avoir de changement de comportement.

@srosset81 Vu que c'est toi qui a publié cette version, verrais-tu autre chose à mettre à jour ici que j'aurais oublié ?

mguihal commented 2 months ago

Ah yes bien vu ! Je l'ai incorporé comme nouvelle migration dans Archipelago pour ne pas oublier de l'appliquer (je suis obligé de tirer le service activitypub que j'avais désactivé auparavant dans l'outil, ce qui le ralentit un peu, mais il y avait un peu trop de logique dans les services pour effectuer chaque requête de manière brute dans la migration). J'ai dû recopier les instructions des méthodes de activitysub/migration puisque ce service n'est pas inclus par défaut ici (et ça permet de ne pas alourdir le middleware avec un service en plus).

Ce travail m'a permis de voir un détail dans le fichier containers.js à propos du container /bots. Il utilise semble-t'il des acceptedTypes inconnu ("Application" venant de la constante ACTOR_TYPES du package activitypub, qui n'appartient à aucune ontologie connue), ce qui faisait planter l'outil de migration. D'ailleurs je ne comprends pas pourquoi ça ne faisait pas planter le middleware dès que je le lance aussi...

J'ai commenté pour l'instant ce container, ce qui fait bien fonctionner le tout, mais je ne comprends pas l'utilité de ce container dans Archipelago en fait, je ne le vois référencé nul part ailleurs. Donc deux solutions :

J'avoue un peu naviguer à vue dès que je touche au middleware, donc je suis preneur d'une aide là-dessus.

srosset81 commented 2 months ago

@mguihal Le container /bot est utilisé par le RelayService, un acteur-bot de type Application y est créé. Voir https://data.virtual-assembly.org/bots C'est ce service qui permet à d'autres instances de faire un miroir de l'instance. Voir https://semapps.org/docs/middleware/sync/mirror La classe Application est valide avec le contexte ActivityStreams, qui le considère comme as:Application. Voir https://www.w3.org/ns/activitystreams.jsonld Je n'ai pas bien compris ce qui faisait l'outil de migration, mais j'espère que ces indications t'aideront.

mguihal commented 2 months ago

Super ! Merci de l'information, c'était ce qu'il me manquait pour que tout fonctionne 👍

Je n'ai pas bien compris ce qui faisait l'outil de migration, mais j'espère que ces indications t'aideront.

Cet outil, comme pour toute base de données, sert juste à historiser les différentes modifications du "schéma" ou des données de la base, qui doivent être modifiés manuellement suite à une mise-à-jour, une nouvelle fonctionnalité ou n'importe quel autre évènement ayant des conséquences sur les données de la base, et ce d'une manière générique à toutes les modifications.

Par exemple pour celle-ci, il y a un nouveau service ActivitysubMigration sur Semapps, mais il fallait dans ce cas-là instancier ce nouveau service, potentiellement à usage unique, et la quantité d'opérations pour l'utilisateur en charge de la maintenance d'une instance Archipelago était accrue, donc la possibilité de faire une erreur aussi.

De plus, il est difficile de savoir si l'opéartion a déjà été faite ou pas une fois celle-ci réalisée (à part en allant rechercher précisément les modifications en base j'imagine). J'ai pris pour hypothèse que la migration que tu proposes était idempotente (on peut la faire plusieurs fois d'affilé sans altérer les résultats), mais ça peut ne pas être le cas pour certains autres changements (imaginons un renommage de container en base, de "Event" en "PublicEvent", si le changement est réalisé 2 fois on se retrouverait avec des "PublicPublicEvent" par exemple).

Avec cet outil de migration,