Je planifie la meilleure façon d’ajouter la prise en charge d’ActivityPub aux Tags, c’est-à-dire permettre aux Tags d’être des acteurs ActivityPub. Un modèle prenant en charge ActivityPub a besoin d’un stockage personnalisé spécifique à l’enregistrement. Une façon d’y parvenir est d’utiliser des champs personnalisés, par exemple :
Il existe d’autres moyens d’obtenir le même résultat, mais les champs personnalisés sont peut-être les plus simples et seraient les plus cohérents avec le modèle de données du plugin ActivityPub et peut-être de Discourse lui-même.
J’ai donc pensé évaluer d’abord l’intérêt pour l’ajout de la prise en charge des champs personnalisés aux Tags, pour lequel je peux faire une PR à discourse/discourse.
J’ai créé une PR pour cela. Notez qu’il s’agit de l’implémentation la plus basique possible, car ni la sérialisation de la liste des balises ni la modification des informations (c’est-à-dire dans l’interface utilisateur des informations sur les balises) ne sont nécessaires :
@sam Je suis curieux de savoir ce que vous en pensez ? Nous décourageons activement l’utilisation de champs personnalisés en interne depuis un certain temps, donc je ne suis pas vraiment favorable à l’ouverture de cela pour les tags.
Je suppose que l’attrait des champs personnalisés réside dans leur structure d’intégration prédéfinie, par exemple le registre de plugins et l’API de plugins. Avoir une manière stable d’intégrer un modèle de base est préférable à la création d’une intégration personnalisée de mon point de vue.
Je vois ce que vous voulez dire à propos des champs personnalisés. Je suppose que je dirais que ces problèmes existent de toute façon. Que les champs personnalisés de balises existent ou non ne changera rien à cela.
Mais il existe d’autres options, donc à vous de voir
Avec le temps, le problème des champs personnalisés est devenu qu’ils sont beaucoup trop flexibles, et les gens ont tendance à stocker des structures énormes et complexes dans un blob.
Je comprends tout à fait que vous souhaitiez une sorte de carte « officielle » sur la façon de procéder.
Je suppose que je vous retourne la question… de quoi parlons-nous exactement ici ?
Chaque fois que Discourse affiche une balise, a-t-il besoin d’afficher quelque chose de spécial ? (c’est un monstre à optimiser car il y a beaucoup d’endroits où les balises sont affichées)
S’agit-il juste de la page des balises ?
S’agit-il juste d’une tâche d’arrière-plan configurée par les administrateurs ?
Je suppose que nous pouvons commencer par là ? Que voulez-vous faire exactement ? Que voient les différents utilisateurs ? etc…
Ils stockeront les données ActivityPub associées à une balise jouant le rôle d’un acteur ActivityPub. Je n’ai besoin d’aucune sérialisation vers des parties du client dans discourse/discourse. L’utilisateur ne verra pas ces données dans aucune partie du client normal discourse/discourse. Les données seront sérialisées vers le client administrateur, avec d’autres données, cependant cela est géré par le plugin dans des routes d’administration dédiées au plugin. Comme vous le dites, la sérialisation dans les routes de balises existantes discourse/discourse (ou le sérialiseur de site) serait délicate, pour diverses raisons et ce n’est pas quelque chose que je souhaite tenter, c’est pourquoi je n’ai pas ajouté de méthodes api préchargées ou modifiables.
En plus d’avoir une API stable avec laquelle travailler, la raison pour laquelle ils sont préférables dans le plugin ActivityPub est que le plugin stocke les activités ActivityPub dans un ensemble distinct de modèles de données, les tables discourse_activity_pub_*, qui s’intègrent ensuite avec discourse/discourse via les API de plugin définies et les champs personnalisés des modèles principaux. Il y a une certaine redondance intentionnelle ici pour assurer une séparation appropriée des préoccupations entre les données Discourse et ActivityPub. Comme Discourse et ActivityPub ont une série de concepts et de modèles de données interdépendants, mais différents, il est nécessaire de maintenir une distinction claire entre les données ActivityPub et les données discourse/discourse pour conserver une certaine clarté (et santé mentale) dans ce qui est un plugin vaste et complexe. L’utilisation de champs personnalisés comme point d’intégration est très utile pour maintenir cette séparation propre et stable.
Il y a une brève explication de cela dans le README du plugin.
Désolé pour le retard @angus. Pouvons-nous essayer d’ajouter la prise en charge des tags à ActivityPub sans champs personnalisés pour les tags ?
Je sais que ce n’est pas cohérent avec le modèle de données que nous utilisons actuellement pour les catégories, mais c’est notre approche préférée. L’ajout de la prise en charge des champs personnalisés pour les tags dans le cœur signifie que nous ouvririons la porte à une prise en charge complète de ceux-ci dans le cœur, je sais que votre PR n’ajoute pas cela, mais cela incitera le prochain développeur à pousser la porte un peu plus loin.
