Domande sull'architettura tecnica di Discourse

Ciao

Tanto tempo fa ero un tecnico, ma non più. Ho detto altrove che sono interessato al design della comunità digitale. Sociologia costruita con la tecnologia

Non so quale sia l’architettura di Discourse, ma sono consapevole che ha temi e plugin. Se ci sono altre parti, le ignoro

Aiuto per favore :slight_smile:

Ho provato a cercare la coppia in vari modi, ma non ottengo nulla che suggerisca “ecco il 101 su cosa/perché. Ad esempio: c’è uno strato di presentazione, uno strato di archiviazione e un processo di selezione tra i due che utilizza queste informazioni per stabilire il contesto per selezionare da uno all’altro. Fuori dalla scatola ottieni x y e z. un plugin è un… quelli presenti nella directory verranno caricati all’avvio del processo del server (o altro) si agganciano all’interfaccia utente/backend/frontend ecc. da…, quelli esistenti sono…, un tema influisce sullo strato di presentazione (?) di quello fuori dalla scatola più i plugin nei seguenti modi…”

Esiste una descrizione del genere che qualcuno non potrebbe indicarmi e che mi porterebbe da 0 a una comprensione sufficiente per poter trovare ciò che esiste attualmente e avere abbastanza comprensione per fare un pensiero fantasioso

perché

allora potrò usarli come blocchi concettuali nella progettazione di comunità per scopi diversi.

Sono interessato a…:
se Discourse potrebbe essere “indurito” per soddisfare gli standard #medical_grade - no, non so quali siano in alcuna giurisdizione particolare, ma so che saranno necessari per gli scopi di interesse e diversi tra le geografie.

Sono interessato all’interfacciamento con strumenti di riabilitazione strumentati e alla codifica per l’estrazione di dati anonimizzati (gdpr compliant) di metriche di progresso ed efficacia come dati di miglioramento per la ricerca.

Sono interessato a come i migliori post possano emergere come la panna, in modo che i nuovi utenti non si trovino di fronte a un’esperienza utente di Discourse che è aliena in un argomento per cui hanno appena scoperto un bisogno acuto in un momento di disorientamento con un corpo di informazioni davanti a loro che arriva a migliaia di post e thread con solo una struttura gerarchica che è accademica e non viscerale per loro…

Le strutture gerarchiche in generale sono migliori da scandagliare per argomenti di potenziale interesse se si può fare un respiro prima di cercare, ma in generale supportano solo schemi di ricerca in profondità, Discord sembra essere un caso emblematico, dove la presunzione è che si conosca già l’argomento, il che potrebbe essere leggermente mitigato dagli hashtag, che è un altro argomento nel mio backlog di lettura.

Forse parte della roba dei bot AI colma il divario? Un altro elemento del backlog… :slight_smile:

Sto anche guardando alcuni video tramite il blog con @jonobacon e potrei essere in grado di fare domande più intelligenti quando li avrò finiti.

Per pensare in modo creativo nel contesto di Discourse ho bisogno di una maggiore comprensione di quali componenti e quali interfacce esistono.

Puoi aiutarmi a indicarmi :slight_smile:
Grazie in anticipo

2 Mi Piace

Sfogliare i plugin, i temi e i componenti dei temi esistenti potrebbe darti un’idea di cosa sia possibile in termini di personalizzazione:

6 Mi Piace

:wave: Ciao @51mon - se sei interessato allo sviluppo del forum Discourse le informazioni qui potrebbero interessarti. :slight_smile:

2 Mi Piace

Grazie :)\n\nPenso che tu mi abbia appena dato un dizionario quando speravo in una guida su come leggere! - hai un’introduzione più gentile sull’argomento di cosa sono queste cose e come funzionano piuttosto che cosa fanno :-)?\n\nCi sono un sacco di cose nei tuoi link, ma non c’è nulla nella panoramica che dica qual è l’architettura di discourse - sono meno preoccupato per quali capacità sono fornite nei plugin ecc. al momento - sto ancora cercando di capire cosa siano realmente.

2 Mi Piace

Grazie, ci darò un’occhiata :slight_smile:

Sono un po’ restio dato che sono intitolati “sviluppo…” e non mi interessa scrivere codice - voglio capire l’architettura

Darò un’occhiata perché al momento non è ovvio se i testi soddisferanno le mie esigenze (speriamo bene)

Ti farò sapere - a meno che, ovviamente, tu non abbia altri suggerimenti :). ?

1 Mi Piace

@51mon Presumo che tu abbia studiato questi?

7 Mi Piace

Non avevo :slight_smile:
Grazie

~~ “~” ~~
[[Modifiche]]

Yikes! Il primo link mi porta all’intestazione di 15 thread

I link due e tre sono pagine di vendita ma almeno sono una pagina - presentano elenchi di funzionalità non descrizioni architettoniche.

E yikes non sono nemmeno sicuro di cosa sia l’ultimo link se non un invito ad accedere a try.discourse.org con thread con più di 100 voci e uno con più di 1.000 da solo -

nessuna mappa. Deve essere un po’ come si sentiva Cook quando avvistò l’Australia e poi passò giorni a navigare lungo la sua costa

Modifica
L’elenco delle funzionalità
La pagina nomina un lungo elenco di cose. Alcune delle cose sono concettuali. Quando un nome si riferisce a un concetto che non è descritto, ti dice solo che c’è una cosa qui ma non trasmette alcuna comprensione o cos’è la cosa - quindi so dalle funzionalità che ce ne sono molte :slight_smile: ma non ho un concetto di cosa posso fare da molte delle funzionalità nominate.
Buono per stabilire l’ampiezza, un buon promemoria per coloro che già conoscono, ma difficile per qualcuno che cerca di capire ottenere comprensione.
Inoltre, da questo elenco di funzionalità non ho idea se si tratti di plugin, temi, pronti all’uso, esclusivi di discourse o comuni in ogni piattaforma
Non sto dicendo che dovrei fare per quella pagina davvero in questa fase sto solo prendendo appunti perché ho un continente da esplorare. Quello che la mia OP chiedeva era un’immagine della terra vista dalla luna, finora non sono nemmeno riuscito a salire in cima all’albero della HMS Endeavor :grin:

Il link numero tre “cos’è discourse” è un mix di presentazione di vendita con altre cose. Non fornisce nemmeno l’architettura - non sto dicendo che dovrebbe, ma poiché non lo fa, non è quello che sto cercando.
Inoltre, non mi convince del tutto - ad esempio, afferma che discourse ha eliminato la complessità, tuttavia il colore rosso utilizzato nell’interfaccia utente cambia in base al numero di mi piace rispetto ai post. Questo è un elemento molto esoterico dell’interfaccia utente. Inoltre, sia che si faccia clic negli elenchi di post non letti sul titolo, sul conteggio delle risposte o su un terzo campo, non so come chiamarlo, si viene portati in posti diversi in un thread. Queste sono tutte variazioni dell’UX intuitive, non annunciate e non segnalate che, finché non si sa che esistono nell’interfaccia utente, saranno confuse.

2 Mi Piace

Ad essere sincero @51mon, non credo di capire la tua domanda. Potresti riformularla in termini semplici e farò del mio meglio per darti una risposta.

8 Mi Piace

È un gentile contatto @JammyDodger - e lo farò quando potrò, ma al momento non posso.

Penso che il mio post iniziale lo dicesse chiaramente nelle mie orecchie, ma chiaramente non lo trasmette chiaramente alle tue orecchie (occhi!).

Proviamo così:

Se fossimo entrambi in piedi e guardassimo un’auto, potremmo avere una discussione come “puoi sederti dentro e ti porterà al supermercato o in spiaggia”. Oppure, in alternativa, potremmo avere una conversazione come “ha le ruote e un motore alimentato a benzina o a batteria, un dispositivo di sterzo e un dispositivo di frenata”.

La conversazione sui freni e sugli indicatori, e se la luce interna si accende e si spegne automaticamente, è una conversazione da sviluppatore. La conversazione sull’andare in spiaggia, portare i bambini a scuola la mattina, e se si può caricare una sedia a rotelle sul retro o trainare una roulotte, è una discussione orientata all’utente che sfiora il tecnico. Per trainare una roulotte è necessario installare un gancio perché non è pronto all’uso. Quando compri l’auto, hai la scelta tra bianco, grigio, nero o forse blu. Sono scelte uniche - forse sono argomenti di amministrazione nel contesto del discorso.

Ora, un aspetto tra molti che mi interessa è se potrei alimentare una comunità con discourse dove le informazioni che si trovano da qualche parte tra l’amministrazione e l’accumulo dei post dei collaboratori e gli ID utente, ecc. ecc. potrebbero dover essere conformi alle normative di grado medico per la protezione dei dati CIA (confidenzialità, integrità e disponibilità). Ma non posso valutare quella domanda quando non conosco l’architettura sottostante.

Se questo non ha reso le cose più chiare, dovrai aspettare che abbia letto tutte le risorse che le persone mi hanno inviato tramite link, in modo da poter porre una domanda comprensibile a coloro che possono rispondere, perché attualmente non riesco a formulare la domanda meglio.
Grazie - :slight_smile:

È un viaggio alla scoperta e sono contento che richiederà del tempo. Quando avrò fatto le scoperte di cui ho bisogno, è molto probabile che le scriva e le doni alla comunità qui, nella speranza che aiutino altri in futuro.

Temo che questo non abbia reso le cose molto più chiare. :slight_smile: Spero che qualcun altro possa intervenire e darti ciò di cui hai bisogno. :crossed_fingers:

Hai già creato un forum in cui giocare? Questo potrebbe aiutarti a esplorare le tue idee e a farti un’idea di ciò che è possibile.

5 Mi Piace

Ciao @51mon.

Sospetto che parte del problema siano le metafore. Qualsiasi cosa si digiti verrà spesso compresa dall’autore. Tuttavia, altri potrebbero avere difficoltà a capirla.


Quindi… eccoci:

Discourse Meta è progettato al centro per essere un framework di community di base.

Fornisce una base fondamentale… che fuori dagli schemi è piuttosto scialba.

Con la tua età e la mia, potresti essere stato coinvolto o a conoscenza dei BBS elettronici Dos.

Un buon numero erano derivati di Telegard BBS, alias Telegard Hacks. (andando fuori tema…)

Tornando all’argomento.

Quindi vuoi costruire un forum Discourse Meta per…

Questo è il tuo punto di partenza. Siediti e pensa a un’idea dello scopo della tua community e di cosa vuoi offrire in termini di funzioni e caratteristiche.

Poi fai 1 passo indietro.

Per avere un’idea più chiara di dove puoi arrivare. Esplora l’elenco delle community che già utilizzano Discourse. Al momento non ho un link a portata di mano. Dare un’occhiata alle community esistenti ti darà un’idea di cosa si può realizzare… e di quanto alcune community siano simili o quanto possano essere diverse in termini di ambito e funzione.

Da qui puoi annotare le caratteristiche che diverse community hanno e che desideri nella tua idea di community.

Puoi decidere se vuoi un hosting a pagamento che possa semplificarti la vita o optare per il controllo completo e l’auto-hosting per avere il controllo totale di una potente estensibilità scegliendo i plugin che desideri. Ma a costo di mantenere tu stesso il VPS.

In entrambi i casi, dovrai ricercare ciò di cui avrai bisogno per avere le funzioni e le caratteristiche disponibili per progettare la tua community.

Quindi, da qui, eseguiamo un esperimento mentale. Fornisci un’idea di community di esempio. Possiamo persino utilizzare una community esistente e chiederci di quali Plugin (se necessari), Theme e Theme component avremmo bisogno per realizzare ciò che questa community ha?

1 Mi Piace

Ciao @Heliosurge
:slight_smile: dimentica quei BBS, ricordo newsnet gestito da UKC a Canterbury tramite linee dial-up a 300 baud e ricordo servizi e client basati su NNTP come freeagent

Concordo pienamente sul fatto che le analogie e, più in generale, le parole disposte in frasi spesso incapsulano solo la comprensione tra le orecchie dello scrittore. Anche se creano comprensione altrove, non c’è garanzia che sia la stessa! :slight_smile:

Proviamo così
Capisco che discourse abbia un lato server che contiene un database di post e di utenti e che sia i post che gli utenti abbiano attributi e siano collegati tra loro. Che questo sia ospitato da qualche parte, l’host potrebbe essere virtuale, una rete di distribuzione di contenuti, ecc.

Capisco che dal lato client ci sia uno strato di presentazione che utilizza i post, le credenziali di autenticazione dell’utente e i diritti di accesso e i collegamenti per creare un feed. Vedo che filosoficamente molte delle strutture utilizzate sono gerarchiche. La gerarchia è oscurata da molti meccanismi di collegamenti incrociati.

Presumo - penso in modo sicuro - che lo schema di colori, ecc. utilizzato dal lato client sia associato al momento dell’esecuzione a un tema che può essere sostituito in modo che l’esecuzione successiva si associ a un nuovo tema e non cambi il contenuto, ma cambi l’aspetto della presentazione e forse anche alcuni componenti stilistici di navigazione funzionale, ma a questo punto divento vago e speculativo.

Sono consapevole che esistono componenti tematici e attualmente ho un modello nella mia testa che dice che una combinazione di componenti tematici crea un tema, ma anche qui sono un po’ incerto. Non ho una chiara comprensione di alcuni esempi di ciò che fa un componente tematico.

Ho meno comprensione dei plugin. Capisco l’aspetto architetturale che sono lato server e quindi si trovano nell’istanza in esecuzione che serve il contenuto. Non capisco bene l’interazione tra un tema e un plugin. Supporrei che se si estendono le capacità lato server, allora si devono estendere quelle di presentazione lato client, ma questa è un’incertezza sull’incertezza.

Inoltre, non so se il modello architetturale completo sia composto da: server, software di servizio, applicazione client/browser, componenti tematici e plugin, o se ci siano altri componenti.

Ho domande come “una community discourse standard non è dietro un paywall o altri meccanismi di monetizzazione, se ne potrebbe aggiungere uno?” I dati sono archiviati in un sistema con un certo grado del triumvirato di CIA - riservatezza, integrità e disponibilità. Può essere rafforzato agli standard richiesti per standard di interoperabilità sanitaria su entrambi i lati dell’Atlantico

Quest’ultimo requisito sposta la conversazione verso l’etica e come il software supporta le preoccupazioni legali, morali e culturali, penso sia pertinente per questo forum. La comprensione architetturale è un prerequisito per la progettazione della soluzione, così come la determinazione dei principi filosofici che modellano le strutture considerate desiderabili, essenziali e indesiderabili/inaccettabili/censurabili e la censura dovrebbe essere elaborata.

1 Mi Piace

Okay, ci siamo. Il database principale di argomenti raggruppati per categorie e organizzati con tag, ad esempio qui.

Ci sono 2 tipi di Theme

  • Base: modifica solo l’aspetto di base di Discourse.
  • Full Theme: modifica l’aspetto ed è pre-confezionato con alcuni Theme component per alterare ciò che può fare con i componenti per cambiare il modo in cui funzionano.

Questa immagine. Invoca il menu della barra laterale.

In basso, dove ho evidenziato con la freccia, Espandi. Hai una raccolta di temi, da quelli base a quelli completi. Sperimenta, scegline uno e vedi come Meta viene alterato in termini di aspetto.

Prova alcuni diversi ed esplora. Penso che questo ti aiuterà a capire meglio cosa possono fare i temi con e senza componenti.

Air Theme, ad esempio, è un tema completo con componenti preinstallati.

2 Mi Piace

Grazie
Penso che questa risposta mi abbia mostrato che i temi vengono caricati sul lato server e che il lato client all’avvio interroga quali temi sono disponibili e quindi con ogni recupero di dati (o istanza di una sessione?) da presentare fornisce un ID tema che il server utilizza per codificare quali elementi HTML verranno inoltrati al client da visualizzare

Inoltre hai detto che l’app deve essere ricostruita. Presumo che sia un processo di modifica dei collegamenti? Almeno stai descrivendo un meccanismo statico, non librerie collegate dinamicamente?

Ancora non ho idea di quali servizi i plugin potrebbero fornire e come un tema interagirebbe se non cambiando la mia icona da un cerchio a un quadrato, cosa che sembra accadere quando ho selezionato quello che hai chiamato, era aria?

A differenza delle vecchie piattaforme forum (vBulletin, phpBB), Discourse non è una raccolta di script lato server (php) separati da un database.

Discourse è composto da due metà: un backend che risiede in Docker e un’applicazione javascript a pagina singola che viene servita al dispositivo client.

Qualsiasi cosa che richieda una modifica del backend influenzerà il container Docker, il che, nelle installazioni più basilari, necessita di un breve periodo di inattività. È a questo che si riferiscono le persone quando dicono che l’app deve essere ricostruita. Il file di configurazione (un documento yml) che controlla come viene costruito il container deve essere modificato e quindi viene emessa una ricostruzione al launcher tramite SSH. L’installazione di plugin richiede una ricostruzione, mentre semplici modifiche a SMTP sono più simili a un riavvio.

L’introduzione di nuovi temi e componenti tematici sono effettivamente modifiche al frontend eseguite all’interno dell’app web in esecuzione. Non comportano tempi di inattività poiché l’app sottostante e il database rimangono effettivamente invariati.

1 Mi Piace

Grazie Steven :slight_smile:

Ho alcune lacune tecniche. La mia esperienza pratica precede Docker di una generazione! infatti ricordo quando la giustificazione di Gosling di Java come linguaggio leggero era la pubblicazione più in voga del mese - all’epoca ero un K&R C, ingres & oracle & sysadmin & dba

Penso di rilevare l’uso delle parole front end e back end come processi in esecuzione sul server e non come lato server/lato client, è corretto?

Abbiamo processi cooperanti con memoria condivisa o pipe o qualcosa tra di loro sul server e poi uno stream di messaggi incapsulato in TCP che invia cose all’IP che ha il software client?

Qualcuno ha disegnato un diagramma a blocchi di questa architettura?

Penso che questo si sia decisamente allontanato da Community :slight_smile: Spostiamolo su Dev poiché riguarda più gli elementi tecnici.

1 Mi Piace

Questo argomento sembra essere un misto di due idee:

  1. “Una panoramica/diagramma di alto livello sarebbe utile per progettare la mia istanza di Discourse”
  2. “Sto cercando di confrontare la funzionalità di Discourse con i miei requisiti ma non riesco a trovare determinate informazioni”.

Il primo punto riguardante l’architettura è stato discusso un po’, tuttavia purtroppo manca ancora un diagramma di alto livello. Si spera che qualcuno con una migliore comprensione possa disegnare qualcosa per noi qui con mermaid, tuttavia posso almeno (sperando) fornire un po’ di guida per i tuoi requisiti originali.

Discourse può soddisfare i requisiti e gli standard di sicurezza delle informazioni mediche/governative/automobilistiche?

Dovresti essere più concreto su quali siano esattamente questi requisiti. Tuttavia, considerando che il mondo medico e automobilistico non sono troppo distanti, posso condividere la mia esperienza nella speranza che sia d’aiuto. Per contesto, gestisco un’istanza innersource per un importante fornitore automobilistico in Germania. È stato un grattacapo legale, ma può essere realizzabile con un livello ingenuo di persistenza, livelli idioti di resilienza e un team legale incredibilmente disponibile e paziente. Seriamente, sii molto gentile con il tuo team legale :laughing:

Le domande più importanti a cui dovrai rispondere sono:

  1. Chi accede alle informazioni?
  • Il pubblico?
  • Il personale?
  • Un misto di personale e pubblico?
  1. Che tipo di informazioni saranno sulla piattaforma?
  • Solo pubblico?
  • Misto di pubblico e interno?
  • Confidenziale? – nota che nel momento in cui pianifichi di ospitare questo sulla piattaforma, le cose diventano molto più difficili
  1. Dove verrà ospitato?
  • in loco
  • Da Discourse o da un altro host

Nel nostro esempio, eravamo solo interni (Personale), solo Informazioni interne (cioè, condividi informazioni aziendali che non sono confidenziali) e originariamente auto-ospitato ma poi spostato su Discourse per l’hosting.

In termini di hosting con Discourse, il nostro Ufficio Sicurezza delle Informazioni non ha riscontrato problemi significativi quando abbiamo scelto di migrare.

Stiamo anche distribuendo queste informazioni in diverse nazioni: Cina, India, Germania, Romania, USA, Francia, ecc. La Cina è stata un po’ un problema, ma il team di Discourse ha fatto un lavoro fantastico per portarci al traguardo con i problemi CDN che abbiamo affrontato.

Nota che la domanda numero 3: “Dove verrà ospitato” è quella che risponde alla maggior parte delle tue domande sulla protezione dei dati e sulla sicurezza.

Login e Autorizzazione

Per il Login, probabilmente vorrai affidarti a SAML. Il team di Discourse ti aiuterà a configurarlo se sei un cliente enterprise. Il nostro IDP è accessibile solo quando ti trovi dietro la VPN della nostra azienda, il che aggiunge un ulteriore livello di sicurezza per noi (cioè, non puoi nemmeno caricare la schermata di accesso a meno che tu non sia sulla nostra rete).

SSH

Inoltre, un’installazione standard fornirà la crittografia SSH. Non sono della CIA, quindi non so se hanno bisogno di più di questo. :male_detective: presumibilmente

Interfacciamento di Discourse con altri strumenti

Affidati all’API

Per l’interfacciamento, l’API di Discourse è tua amica. Puoi ottenere e impostare dati utilizzando una chiave API e un po’ di Python.

C’è un ottimo set di esempi qui: Discourse REST API comprehensive examples

Anonimizzazione dei dati utente per essere conformi al GDPR

In termini di GDPR, potresti estrarre i dati dalla piattaforma e omettere l’utente al punto di origine eseguendo una query nell’esploratore dati.

Questo è in contrasto con l’uso dell’API di Discourse, dove la risposta JSON include tipicamente informazioni complete sul post come:

  • Il contenuto del post (HTML cotto e Markdown grezzo)
  • L’ID del post
  • L’ID dell’argomento a cui appartiene
  • Il nome utente del poster
  • Il numero del post all’interno dell’argomento
  • I timestamp di creazione e ultimo aggiornamento del post
  • Il numero di like, risposte, citazioni e così via.

Come ottenere post in evidenza e un’interfaccia utente familiare?

Potresti non averlo visto, ma potresti combinare questo tema:

con qualcosa del genere:

3 Mi Piace

Per la legge HIPAA negli Stati Uniti, con qualsiasi tipo di dato di cartella clinica, i professionisti possono condividerlo con familiari/amici/caregiver + chiunque altro scelga il paziente se firmano un modulo ufficiale di autorizzazione alla divulgazione delle informazioni. Questi di solito hanno una scadenza di solo un certo numero di mesi o anni.

Un semplice diagramma per questo sarebbe: tutti i dati medici si trovano in un gigantesco caveau chiuso a chiave che non può mai essere aperto per alcuna emergenza, a meno che il personale dei servizi di emergenza non abbia firmato documenti dal paziente.

A meno che: il paziente non sia incosciente, specialmente a lungo termine in coma o altrimenti non sano di mente, e/o dichiarato da un tribunale + giudice incapace di occuparsi dei propri affari, nel qual caso qualcun altro può essere nominato per questo.

Entrambi questi scenari potrebbero essere rappresentati da una chiave che può aprire il caveau, quindi spostare alcuni dati medici in un caveau secondario con accesso limitato solo a persone specifiche.

Che potrebbe essere un gruppo di persone, ma dovrebbero essere nominate individualmente nella maggior parte dei casi, credo, per essere autorizzate ad avere accesso ai dati medici.

https://www.cdc.gov/phlp/publications/topic/hipaa.html

1 Mi Piace