Sto pianificando come aggiungere al meglio il supporto ActivityPub ai Tag, ovvero consentire ai Tag di essere attori ActivityPub. Un modello con supporto ActivityPub necessita di uno storage personalizzato specifico per il record. Un modo per farlo è tramite campi personalizzati, ad esempio
Esistono altri modi per ottenere lo stesso risultato, ma i campi personalizzati sono forse i più semplici e sarebbero più coerenti con il modello di dati sia del plugin ActivityPub che, forse, di Discourse stesso.
Quindi ho pensato di valutare prima l’interesse nell’aggiungere il supporto CustomField ai Tag, per il quale posso creare una PR a discourse/discourse.
Ho creato una PR per questo. Nota che questa è l’implementazione più basilare possibile, poiché né la serializzazione dell’elenco dei tag né la modifica delle informazioni (cioè nell’interfaccia utente delle informazioni dei tag) sono necessarie:
@sam Sono curioso di sapere cosa ne pensi? Abbiamo attivamente scoraggiato l’uso di campi personalizzati internamente per un po’ di tempo, quindi non sono molto propenso ad aprire questo per i tag.
Immagino che l’attrazione dei campi personalizzati sia che hanno una struttura di integrazione predefinita, ad esempio il registro dei plugin e l’API dei plugin. Avere un modo stabile di integrare con un modello di base è preferibile a creare un’integrazione personalizzata dal mio punto di vista.
So cosa intendi riguardo ai campi personalizzati. Immagino che direi che quei problemi esistono comunque. L’esistenza o meno dei campi personalizzati per i tag non cambierà questo.
Col tempo, il problema dei campi personalizzati è diventato che sono troppo flessibili e le persone tendono a memorizzare strutture enormi e complesse in un blob.
Capisco perfettamente che tu voglia una sorta di mappa “ufficiale” su come farlo.
Suppongo che ti restituisca la domanda… di cosa stiamo parlando esattamente?
Ogni volta che discourse visualizza un tag, deve visualizzare qualcosa di speciale? (questo è un mostro da ottimizzare perché ci sono molti posti in cui vengono visualizzati i tag)
È solo la pagina dei tag?
È solo un’attività in background configurata dagli amministratori?
Suppongo che iniziamo da lì? Cosa vuoi fare esattamente? Cosa vedono i vari utenti? ecc…
Memorizzeranno i dati di ActivityPub associati a un tag che svolge il ruolo di un attore di ActivityPub. Non ho bisogno di alcuna serializzazione in alcuna parte del client in discourse/discourse. L’utente non vedrà questi dati in alcuna parte del normale client discourse/discourse. I dati verranno serializzati nel client admin, insieme ad altri dati, tuttavia ciò è gestito dal plugin in percorsi admin dedicati al plugin. Come dici tu, la serializzazione negli attuali percorsi di tag discourse/discourse (o nel serializzatore del sito) sarebbe complicata, per varie ragioni e non è qualcosa che voglio tentare, motivo per cui non ho aggiunto metodi api di precaricamento o modificabili.
Oltre ad avere un’API stabile con cui lavorare, il motivo per cui sono preferibili nel plugin ActivityPub è che il plugin memorizza le attività di ActivityPub in un set separato di modelli di dati, le tabelle discourse_activity_pub_*, che quindi si integrano con discourse/discourse tramite le API del plugin definite e i campi personalizzati dei modelli core. C’è una certa ridondanza intenzionale qui per garantire una corretta separazione delle responsabilità tra i dati di Discourse e ActivityPub. Poiché Discourse e ActivityPub hanno una serie di concetti e modelli di dati interrelati, ma diversi, mantenere una chiara distinzione tra i dati di ActivityPub e i dati di discourse/discourse è necessario per mantenere una certa chiarezza (e sanità mentale) in quello che è un plugin grande e complesso. L’uso di campi personalizzati come punto di integrazione è molto utile per mantenere questa separazione pulita e stabile.
C’è una breve spiegazione di questo nel readme del plugin.
Mi scuso molto per il ritardo qui @angus. Possiamo provare ad aggiungere il supporto per i tag ad ActivityPub senza campi personalizzati per i tag?
So che non è coerente con il modello di dati che stiamo attualmente utilizzando lì per le categorie, ma è il nostro approccio preferito. Aggiungere il supporto per i campi personalizzati per i tag nel core significa che apriremo la porta al supporto completo per essi nel core, so che la tua PR non aggiunge questo, ma spingerà il prossimo sviluppatore a spingere la porta leggermente più aperta.
