Mi sto aggiornando su questa discussione, ma penso sicuramente che la risposta sia sì
A causa del successo della nostra community aziendale (sia con i nostri utenti, sia all’interno della nostra attività), il nostro team di documentazione ci ha contattato e ha chiesto se potessimo creare un sistema di commenti per tutta la documentazione di documentation.sailpoint.com. Da quello che sembra, saremo in grado di fare quasi tutto ciò che vogliamo realizzare come minimo indispensabile:
Incorporare commenti (funzionalità di incorporamento)
Vogliamo anche utilizzare utenti diversi per pubblicare e applicare diversi set di tag, in base all’incorporamento. Questa funzionalità arriverà molto presto:
Da lì, tutto il resto che il team di documentazione (e il mio team) voleva era all’interno di Discourse per poter separare efficacemente questa esperienza dal resto del nostro forum “quotidiano”, pur dando alle persone la possibilità di commentare, ricevere notifiche delle risposte, ecc.
Possibilità di designare quali utenti possono e non possono commentare
Assegnare moderatori di categoria agli argomenti associati
Sopprimere questa pletora di categorie per questi documenti dal nostro sito principale
categoria non ricercabile
componente tematico utilizzato per nasconderla dall’elenco delle categorie principali
soppressa dal digest
aggiunta alle categorie predefinite silenziate
Commenti rimossi dopo n giorni
Alcune altre impostazioni…
Mi piacerebbe sicuramente vedere implementate molte delle funzionalità menzionate qui!
L’obiettivo è consentire agli utenti di creare commenti su https://documentation.sailpoint.com/, o va bene incorporare semplicemente i commenti sul sito di documentazione e far visitare agli utenti il tuo sito Discourse per commentare gli articoli?
Il primo è una funzionalità che sarei lieto di avere e mi piacerebbe molto (leggi: per favore, costruiscila, CDCK), ma l’ultima soddisfa i nostri requisiti minimi, almeno.
In realtà, esplorerò un’idea nel prossimo futuro di far sì che Discourse fornisca la nostra documentazione markdown (no, non in argomenti, ma in tradizionali documenti in stile markdown) nel qual caso i commenti, e l’iscrizione per crearli, sarebbero all-inclusive. Ma quell’esplorazione non è ancora iniziata.
Con l’approccio su cui sto lavorando ora, sarebbe tecnicamente possibile consentire la generazione di commenti di Discourse direttamente sulle pagine MkDocs, ma richiederebbe l’uso di un framework lato server (Remix, Rails, ecc.) per servire le pagine MkDocs. Ciò renderebbe possibile autenticare gli utenti (con DiscourseConnect) sul sito di documentazione e consentirebbe anche l’uso di un database in memoria per memorizzare nella cache i commenti restituiti in precedenza.
(Modifica: giusto per essere chiari, sto parlando di usare Discourse come provider di identità per il sito web, non il sito web come provider di identità per Discourse. Quest’ultimo approccio funziona, ma è troppo inflessibile per la maggior parte dei casi d’uso.)
Sarebbe comunque un grande cambiamento da chiedere al tuo team.
Sono sicuro che dalla tua prospettiva sarebbe più semplice se ciò fosse realizzato interamente all’interno di Discourse, ma è anche possibile utilizzare Discourse come sistema di gestione dei contenuti. In tal caso, la documentazione markdown verrebbe generata come normali topic di Discourse. I webhook di Discourse verrebbero utilizzati per attivare la generazione di una pagina di documentazione su un sito esterno. Questa è in realtà la base del sito demo dei commenti di Discourse che sto configurando.
Poiché questo argomento è stato collegato oggi, ho pensato di aggiornarlo con le conclusioni a cui sono giunto dopo aver lavorato un po’ sull’idea.
Penso ancora che Discourse sarebbe una buona piattaforma di commenti per i motivi che ho delineato nell’OP.
In termini di come farlo, penso che il lavoro debba essere fatto dal lato Discourse, idealmente migliorando lo script di incorporamento dei commenti di Discourse. Questo potrebbe essere fatto in modo incrementale.
È tecnicamente possibile utilizzare Discourse come server per una piattaforma di commenti facendo tutto il lavoro su un client Discourse (ad esempio, il plugin WP Discourse), ma a causa della necessità di gestire lo stato tra il client e Discourse e aggirare i problemi di rate limiting, diventa un problema complesso. È decisamente più complesso di qualcosa di cui voglio essere responsabile della manutenzione.
Alcuni post in questo argomento hanno indicato che le persone sarebbero interessate a consentire semplicemente agli utenti di creare commenti Discourse su un sito di blog. Dal mio punto di vista non è una grande soluzione, ma può essere ottenuta ora con l’API di Discourse. Dove le cose si complicano è nel tentativo di creare un sistema di commenti completo, in cui gli utenti possano interagire con i commenti di Discourse su un sito web in modo simile a come si aspetterebbero di interagire con i commenti su un tipico sito di notizie mainstream.
Dato l’uso di ActivityPub e WP Discourse, ritengo che i commenti bidirezionali tramite javascript incorporato siano realizzabili. Lo script di incorporamento conterrebbe quanto segue:
“Lettura” non autenticata che funziona in modo simile all’attuale incorporamento js (con alcune ottimizzazioni).
Client remoto (ovvero il browser dell’utente) registra un client di chiave API utente, specifico per la sessione dell’utente e memorizza i dettagli pertinenti nello storage locale del browser.
All’utente viene presentato “Accedi per commentare”.
L’utente si autentica (con Discourse) per recuperare una chiave API utente di sessione che viene memorizzata nello storage locale del browser.
Ogni attività (commento, like, ecc.) viene pubblicata direttamente su un endpoint dedicato con appropriate misure di sicurezza, gestione e gestione delle attività.
Con il budget giusto, penso di poter rendere la v1 pronta per la produzione e integrata con discourse/discourse in 6-8 mesi. Dopo il rilascio iniziale, potrei fare quanto segue:
Aggiungere supporto esplicito per Wordpress, Ghost e altre piattaforme selezionate.
Prova a implementarlo in un modo che abbia senso per gli utenti non tecnici. Piattaforme esistenti come Disqus e i commenti di Facebook probabilmente offrono buoni esempi.
Altre opzioni di autenticazione:
il sito client diventa un client DiscourseConnect. Questo è semplice da implementare, ma richiede l’aggiunta di codice lato server al sito client.
gli utenti accedono direttamente a Discourse tramite l’iframe
La mia riluttanza a sviluppare questo puramente lato client è nata dalla considerazione dei problemi del sistema che funziona su qualsiasi scala. Essenzialmente, ho dovuto mettere in coda le richieste API e gestire le risposte dalle richieste in coda. Non mi sembrava abbastanza robusto per gestire, diciamo, 1000 utenti concorrenti. Avrei preoccupazioni simili, ma per ragioni diverse, con l’approccio dell’embed javascript. Sospetto che sarebbe molto più facile da gestire rispetto al tentativo di sincronizzare tutto sul client, però.
Ci ho riflettuto più a fondo ieri, dato che l’argomento è stato ripreso (motivo per cui ho finito per postare qui). Penso che una soluzione solo lato client (cioè un embed javascript) sia l’unica che abbia davvero senso qui. Altrimenti stiamo essenzialmente parlando di una serie di implementazioni specifiche per piattaforma, ognuna con il proprio set di problemi.
Hai ragione sul fatto che la concorrenza e il carico siano problemi. Ci sono significativi problemi di carico e concorrenza con ActivityPub, poiché un singolo post ActivityPub può esporti a molte richieste in entrata e in uscita dal Fediverso. In quel contesto, questo potrebbe essere in realtà leggermente più facile poiché i client remoti sono controllati. Inoltre, in questo caso, la concorrenza e il carico sono veramente problemi solo lato server (cioè lato Discourse) e, sebbene siano problemi, penso che dovrebbero essere risolvibili tramite job in background, caching e mutex. Ma sì, problemi importanti da considerare.
Ad essere sinceri, la mia più grande preoccupazione qui è la tempistica.
Composer v2 è dietro l’angolo, sarebbe folle intraprendere questa avventura e non fare affidamento sul nostro nuovo composer, ma c’è una montagna di lavoro di cui abbiamo bisogno in anticipo per rendere fattibile il suo utilizzo in un’app leggera.
Penso che la cosa giusta da fare qui sia monitorare questo spazio per il nuovo composer per circa 2-3 mesi e poi rivisitare la questione.
Penso che possa essere fatto in parallelo. Devi apportare 2 modifiche al discorso.
Il pulsante “Rispondi” dovrebbe essere visibile agli utenti non registrati.
E quando gli utenti non registrati fanno clic su questo pulsante, dovrebbe essere visualizzato:
Successivamente, devi capire come utilizzare l’inserimento di commenti. Probabilmente si tratterà di piccole modifiche al codice piuttosto che di molto lavoro.
Mi stavo chiedendo se ci sia ancora interesse nello sviluppare questa funzionalità, ora che Composer v2 è uscito. Metto il mio voto sul fatto che sia ancora qualcosa che mi piacerebbe vedere e usare.
