Ich plane, wie ich ActivityPub-Unterstützung am besten zu Tags hinzufüge, d. h. Tags als ActivityPub-Akteure zulasse. Ein Modell mit ActivityPub-Unterstützung benötigt recordspezifischen benutzerdefinierten Speicher. Eine Möglichkeit, dies zu erreichen, sind benutzerdefinierte Felder, z. B.
Es gibt andere Möglichkeiten, dasselbe Ergebnis zu erzielen, aber benutzerdefinierte Felder sind vielleicht die einfachste und wären am konsistentesten mit dem Datenmodell sowohl des ActivityPub-Plugins als auch möglicherweise von Discourse selbst.
Daher wollte ich zuerst das Interesse am Hinzufügen von CustomField-Unterstützung zu Tags ausloten, wofür ich einen PR an discourse/discourse machen kann.
Ich habe einen PR dafür erstellt. Beachten Sie, dass dies die grundlegendste Implementierung ist, da weder die Serialisierung der Tag-Liste noch die Bearbeitung von Informationen (d. h. in der Tag-Info-Benutzeroberfläche) erforderlich ist:
@sam Ich bin neugierig, was Sie dazu sagen? Wir haben die Verwendung von benutzerdefinierten Feldern intern seit einiger Zeit aktiv abgeraten, daher bin ich nicht wirklich daran interessiert, dies für Tags zu öffnen.
Ich schätze, der Reiz von benutzerdefinierten Feldern liegt darin, dass sie eine vordefinierte Integrationsstruktur haben, z. B. das Plugin-Registry und die Plugin-API. Aus meiner Sicht ist ein stabiler Weg zur Integration mit einem Kernmodell der Entwicklung einer benutzerdefinierten Integration vorzuziehen.
Ich weiß, was Sie mit benutzerdefinierten Feldern meinen. Ich würde sagen, dass diese Probleme ohnehin bestehen. Ob Tag-Benutzerdefinierte Felder existieren oder nicht, wird daran nichts ändern.
Aber es gibt andere Optionen, also liegt es an Ihnen
Im Laufe der Zeit hat sich das Problem mit benutzerdefinierten Feldern darin gezeigt, dass sie viel zu flexibel sind und die Leute dazu neigen, riesige komplexe Strukturen in einem Blob zu speichern.
Ich verstehe vollkommen, dass Sie eine Art „offizielle“ Karte dafür wünschen.
Ich vermute, ich gebe die Frage an Sie zurück… worüber genau sprechen wir hier?
Muss jedes Mal, wenn Discourse ein Tag anzeigt, etwas Besonderes angezeigt werden? (das ist ein Monster zur Optimierung, da Tags an vielen Stellen angezeigt werden)
Geht es nur um die Tag-Seite?
Ist dies nur eine Hintergrundaufgabe, die von Administratoren konfiguriert wird?
Ich denke, fangen wir dort an? Was genau möchten Sie tun? Was sehen verschiedene Benutzer? usw.
Sie werden ActivityPub-Daten speichern, die mit einem Tag verbunden sind, der die Rolle eines ActivityPub-Akteurs ausführt. Ich benötige keine Serialisierung für Teile des Clients in discourse/discourse. Der Benutzer wird diese Daten in keinem Teil des normalen discourse/discourse-Clients sehen. Die Daten werden zusammen mit anderen Daten an den Admin-Client serialisiert, dies wird jedoch vom Plugin in dedizierten Plugin-Admin-Routen verwaltet. Wie Sie sagen, wäre die Serialisierung in den bestehenden discourse/discourse-Tag-Routen (oder dem Site-Serializer) aus verschiedenen Gründen schwierig und nichts, was ich versuchen möchte, weshalb ich keine Preload- oder bearbeitbaren API-Methoden hinzugefügt habe.
Zusätzlich zu einer stabilen API, mit der gearbeitet werden kann, sind sie im ActivityPub-Plugin vorzuziehen, da das Plugin ActivityPub-Aktivitäten in einem separaten Satz von Datenmodellen speichert, den discourse_activity_pub_*-Tabellen, die dann über die definierten Plugin-APIs und benutzerdefinierten Felder der Kernmodelle mit discourse/discourse integriert werden. Es gibt hier eine beabsichtigte Redundanz, um eine ordnungsgemäße Trennung der Zuständigkeiten zwischen Discourse- und ActivityPub-Daten sicherzustellen. Da Discourse und ActivityPub eine Reihe von miteinander verbundenen, aber unterschiedlichen Konzepten und Datenmodellen haben, ist die Beibehaltung einer klaren Unterscheidung zwischen ActivityPub-Daten und discourse/discourse-Daten notwendig, um etwas Klarheit (und geistige Gesundheit) in einem großen und komplexen Plugin zu bewahren. Die Verwendung von benutzerdefinierten Feldern als Integrationspunkt ist sehr nützlich, um diese Trennung sauber und stabil zu halten.
Eine kurze Erklärung dazu finden Sie in der README-Datei des Plugins.
Es tut mir so leid wegen der Verzögerung, @angus. Können wir versuchen, Tag-Unterstützung zu ActivityPub hinzuzufügen, ohne benutzerdefinierte Tag-Felder zu verwenden?
Ich weiß, dass dies nicht mit dem Datenmodell übereinstimmt, das wir derzeit für Kategorien verwenden, aber es ist unser bevorzugter Ansatz. Das Hinzufügen von Unterstützung für benutzerdefinierte Felder für Tags im Kern bedeutet, dass wir die Tür für eine vollständige Unterstützung für sie im Kern öffnen würden. Ich weiß, dass Ihr PR dies nicht hinzufügt, aber es wird den nächsten Entwickler dazu anregen, die Tür noch ein Stück weiter zu öffnen.
