LiveKit-Status im Serializer der Seiteneinstellungen ausgeben

Unterstützung
1

@Falco Ist es möglich, in den Site-Einstellungen bzw. im Serializer einen öffentlichen Check bereitzustellen, der angibt, ob LiveKit konfiguriert ist – neben voice_enabled?

Aktuell ist voice_enabled für den Client verfügbar, aber es gibt kein öffentliches Signal dafür, ob eine Site LiveKit bereitstellen kann. Das einzige LiveKit-bezogene Site-Attribut, voice_livekit_per_room_available, ist auf das Checkbox-Feld im Raumformular beschränkt. Es liefert unter der all_rooms-Richtung false zurück und kann daher nicht verwendet werden, um die Frage zu beantworten, ob die Site überhaupt LiveKit einsetzt.

RoomSerializer#expected_transport deckt den Fall pro Raum gut ab, erfordert aber zunächst das Abrufen der Räume. Zudem liefert es bei deaktiviertem voice_public_access einen leeren Wert zurück, selbst auf einer Site, auf der LiveKit vollständig konfiguriert ist.

Wäre etwas in dieser Art akzeptabel? Es leitet sich aus dem vorhandenen Zustand ab, gibt keine Zugangsdaten oder Richtungsdetails preis und benötigt keinen neuen Endpunkt.

Es würde in plugins/voice/plugin.rb nach dem Block für voice_livekit_per_room_available und direkt vor der Zeile Voice::DefaultRoomSeeder.ensure! eingefügt:

# Öffentliches Signal ohne Zugangsdaten, dass die Site LiveKit bereitstellen kann.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end

2

voice_enabled ist über die JSON-API überhaupt nicht erreichbar: /site.json enthält keinen site_settings-Schlüssel. Das einzige öffentliche Signal dafür, dass Voice auf einer Site aktiv ist, ist daher das Vorhandensein von voice_assets_path.

Ich bitte um zwei öffentliche, ohne Anmeldeinformationen benötigte Boolesche Werte, damit ein Client entscheiden kann, ob Voice vor dem Abruf von Räumen angezeigt werden soll. Beide werden aus dem bestehenden Zustand abgeleitet und erfordern keinen neuen Endpunkt, in plugins/voice/plugin.rb:

Zeile 141, über voice_public_access:

# Öffentliche, ohne Anmeldeinformationen benötigte Signale für API-Clients, dass Voice aktiviert ist.

add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }

Zeile 152, über voice_livekit_per_room_available:

# Ob Joins überhaupt LiveKit verwenden können. Ein reines Ja/Nein: keine URL, kein Schlüssel und
# kein Policy-Wert. Das nachfolgende Attribut pro Raum steuert nur das SFU-Checkbox-Feld im
# Raumformular und liefert unter der all_rooms-Policy false.

  add_to_serializer(:site, :voice_livekit_available) do

    Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"

  end

Hier wird nichts Neues offengelegt: expected_transport ist ein ungatedes Attribut in RoomSerializer (Zeile 30, definiert in Zeile 150) und rooms#index überspringt die Anmeldung (rooms_controller.rb:18), sodass „livekit“ / „mesh“ bereits pro Raum anonym lesbar ist. Dies beantwortet die Frage einfach, ohne einen Raumabruf, der leer zurückkommen könnte.

3

Bitte erwähne Teammitglieder nicht so pauschal (ich habe die Erwähnungen entfernt).

Es könnte helfen, wenn du beschreibst, welches Endziel du mit diesen zusätzlichen Informationen verfolgst. Ohne eine Begründung, wofür du die Informationen verwenden möchtest, ist es schwer, eine Funktionsanfrage zu beantworten.

4

Entschuldigung, dass ich eine Frage in einem Ankündigungs-Thread gestellt habe. Ich wurde an den Support verwiesen, wodurch ich nicht wusste, wen ich ansprechen sollte, da es sich um eine Feature-Anfrage und nicht um eine Fehlerbehebung handelt. Nach einer fünfständigen Recherche habe ich die Mitglieder getaggt, die für den Kern-Commit/Merge von Voice verantwortlich sind.

Um etwas Kontext zu liefern: Ich habe eine Anwendung, die als Multi-Client für Discourse-Communities fungiert, wobei jede Community unterschiedlich konfiguriert ist. Beim Start baut die Anwendung daher die Navigation für die jeweilige Site auf, auf der sich der Benutzer befindet. Chat wird angezeigt, wenn Chat aktiviert ist, und ich möchte, dass Voice angezeigt wird, wenn Voice aktiviert ist und aus der App heraus tatsächlich beitreten kann.

Die App verbindet sich über LiveKit und kann kein Mesh verwenden. Auf einer Mesh-Site möchte ich Voice daher ganz aus der Navigation ausblenden, anstatt Räume anzuzeigen, bei denen die Verbindung fehlschlägt und die App dadurch kaputt wirkt.

Der Ablauf sieht also so aus: Beim Start einmal die Site-Informationen lesen, entscheiden, ob Voice für diese Site in der App erscheinen soll, und dann, sobald der Benutzer einen Raum öffnet, expected_transport pro Raum verwenden. Die beiden Booleans sind nur der erste Schritt, und ohne sie würde ich entweder eine Funktion anzeigen, die nicht funktionieren kann, oder eine verbergen, die es kann.

Alternativ könnte ich in der Anwendung unabhängig davon, ob die Funktion aktiviert ist oder nicht, eine globale Warnung mit dem Text „In diesem Forum nicht verfügbar“ einblenden. Dieser Ansatz erschien mir jedoch als der bessere, weshalb ich den Einstiegspunkt identifiziert habe und den Code samt Kommentaren bereitgestellt habe.

5

Danke für die Erläuterung! Die Anfrage ergibt Sinn.

Das Voice-Plugin ist neu und befindet sich noch im experimentellen Stadium. In den kommenden Wochen und Monaten wird es wahrscheinlich Änderungen durchlaufen, insbesondere interne Anpassungen. Wir sind offen dafür, diese Informationen in irgendeiner Form bereitzustellen, können aber noch nicht sagen, in welcher Form genau. Das hängt davon ab, wie sich die LiveKit-Integration weiterentwickelt.

6

Wenn du denkst, dass 5 Stunden Wartezeit zu viel sind, bist du dem Konzept der asynchronen Kommunikation in Foren wahrscheinlich noch neu. Willkommen!

Ich werde dies untersuchen und etwas ausarbeiten, das wir verwenden können.

7

Ich glaube, du hast mich missverstanden. Ich war von 1 bis 5 Uhr morgens wach, um zu überprüfen, was erledigt wurde und welche Merges vorgenommen wurden. So habe ich die Teammitglieder gefunden, die ich ursprünglich markiert hatte. Es geht nicht darum, dass ich 5 Stunden auf eine Antwort warte. Die App wurde bereits zur Prüfung eingereicht und nutzt das Standardsystem, das ich bereits habe.

Das ist für mich in Ordnung, nehmt euch so viel Zeit, wie ihr braucht. Ich habe meine Tests über einen Zeitraum von 6 Monaten durchgeführt, und es hat etwas Feinjustierung für das Skalieren gebraucht.