@Falco È possibile esporre un controllo pubblico nelle impostazioni del sito/serializer per verificare se LiveKit è configurato, accanto a voice_enabled?
Attualmente voice_enabled è esposto al client, ma non esiste un segnale pubblico per sapere se un sito può servire LiveKit. L’unico attributo del sito relativo a LiveKit, voice_livekit_per_room_available, è limitato alla casella di controllo del modulo della stanza, quindi restituisce false con la policy all_rooms e non può essere usato per rispondere alla domanda “questo sito usa LiveKit in assoluto?”.
RoomSerializer#expected_transport gestisce bene il caso per stanza, ma richiede di recuperare prima le stanze e restituisce vuoto quando voice_public_access è disattivato, anche su un sito dove LiveKit è completamente configurato.
Qualcosa del genere sarebbe accettabile? È derivato dallo stato esistente, non espone credenziali né dettagli di policy e non richiede nuovi endpoint.
Andrebbe inserito in plugins/voice/plugin.rb, dopo il blocco voice_livekit_per_room_available e subito prima della riga Voice::DefaultRoomSeeder.ensure!:
# Segnale pubblico, senza credenziali, che il sito può servire LiveKit in assoluto. add_to_serializer(:site, :voice_livekit_available) do Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled" end
voice_enabled non è raggiungibile affatto dall’API JSON: /site.json non contiene la chiave site_settings. Quindi l’unico segnale pubblico che indica che la voce è attiva su un sito è la presenza di voice_assets_path.
Ciò che chiedo sono due booleani pubblici, senza credenziali, in modo che un client possa decidere se mostrare la voce prima di recuperare le stanze. Entrambi sono derivati dallo stato esistente e non richiedono un nuovo endpoint, in plugins/voice/plugin.rb:
Alla riga 141, sopra voice_public_access:
#Segnali pubblici, senza credenziali, per i client API che la voce è abilitata.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
Alla riga 152, sopra voice_livekit_per_room_available:
# Se le join possono utilizzare LiveKit. Una semplice risposta sì/no: nessuna URL, chiave o
# valore di policy. L'attributo per stanza di seguito limita solo la casella SFU del modulo stanza,
# e legge false sotto la policy all_rooms.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end
Questo non espone nulla di nuovo: expected_transport è un attributo non protetto su RoomSerializer (riga 30, definito a 150) e rooms#index salta il login (rooms_controller.rb:18), quindi “livekit” / “mesh” è già leggibile anonimamente per stanza. Questo risponde semplicemente senza un recupero della stanza che potrebbe tornare vuoto.
Per favore, non menzionare i membri del team in blocco in quel modo (ho rimosso le menzioni).
Potrebbe essere utile descrivere qual è il tuo obiettivo finale per queste informazioni aggiuntive. È difficile rispondere a una richiesta di funzionalità senza alcuna giustificazione su come verranno utilizzate le informazioni.
Mi scuso per aver posto una domanda su un annuncio e per essere stato reindirizzato al supporto, il che mi ha lasciato senza sapere a chi rivolgermi, dato che si tratta di una richiesta di funzionalità e non di un problema tecnico. Dopo aver esaminato la situazione per le ultime 5 ore, ho coinvolto i membri responsabili dei commit e delle merge principali relative alla voce.
Tuttavia, per fornire un po’ di contesto: ho un’applicazione che funge da client multiplo per le community di Discourse, ciascuna configurata in modo diverso. Al momento dell’avvio, l’app costruisce la navigazione per il sito su cui si trova l’utente. La chat viene visualizzata se è abilitata, e vorrei che la voce venisse mostrata se è abilitata e realmente raggiungibile dall’app.
L’app si connette tramite LiveKit e non supporta il mesh, quindi su un sito configurato per il mesh preferisco escludere completamente la voce dalla navigazione, piuttosto che mostrare stanze che fallirebbero nel collegamento, facendo sembrare l’applicazione rotta.
Il flusso di lavoro è quindi il seguente: leggere le informazioni del sito una volta all’avvio, decidere se la voce debba far parte dell’app per quel sito specifico, e poi utilizzare expected_transport per ogni stanza quando l’utente la apre. I due valori booleani sono solo il primo passo, e senza di essi mi troverei a mostrare una funzionalità che non può funzionare o a nasconderne una che potrebbe funzionare.
In alternativa, potrei inserire un avviso globale “Non disponibile in questo forum” all’interno dell’applicazione, indipendentemente dall’abilitazione, ma questa mi è sembrata l’opzione migliore: ho quindi individuato il punto di ingresso e ho fornito il codice con i relativi commenti.
Il plugin vocale è nuovo e si trova in una fase sperimentale. È probabile che subisca modifiche nelle prossime settimane e nei prossimi mesi, in particolare a livello interno. Siamo aperti all’idea di rendere disponibile queste informazioni in qualche modo, ma non possiamo ancora essere certi di quale forma assumerà. Dipenderà da come evolverà l’integrazione con LiveKit.
Credo che tu abbia frainteso: ero sveglio dalle 1 alle 5 del mattino per rivedere ciò che era stato fatto e le merge, ed è così che ho trovato i membri del team che avevo inizialmente menzionato. Non è che sto aspettando una risposta da 5 ore. L’app è già stata inviata per la revisione e utilizza il sistema predefinito che ho già a disposizione.
Per me va bene così, prenditi tutto il tempo che ti serve. Ho effettuato i miei test nel corso di 6 mesi; ci è voluto un po’ di messa a punto per la scalabilità.