@Falco ¿Es posible exponer una comprobación pública en la configuración del sitio/serializador para saber si LiveKit está configurado, junto con voice_enabled?
Hoy en día, voice_enabled se expone al cliente, pero no hay ninguna señal pública sobre si un sitio puede servir LiveKit. El único atributo del sitio relacionado con LiveKit, voice_livekit_per_room_available, está limitado a la casilla de verificación del formulario de la sala, por lo que devuelve false bajo la política all_rooms y no se puede usar para responder a la pregunta “¿este sitio usa LiveKit en absoluto?”.
RoomSerializer#expected_transport cubre bien el caso por sala, pero eso requiere obtener las salas primero, y devuelve un resultado vacío cuando voice_public_access está desactivado, incluso en un sitio donde LiveKit está completamente configurado.
¿Sería aceptable algo como esto? Se deriva del estado existente, no expone credenciales ni detalles de política y no requiere ningún nuevo punto de entrada (endpoint).
Se colocaría en plugins/voice/plugin.rb, después del bloque voice_livekit_per_room_available y justo antes de la línea Voice::DefaultRoomSeeder.ensure!:
# Señal pública y sin credenciales de que el sitio puede servir LiveKit en absoluto. add_to_serializer(:site, :voice_livekit_available) do Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled" end
voice_enabled no es accesible en absoluto desde la API JSON: /site.json no incluye la clave site_settings. Por lo tanto, la única señal pública de que el audio está activo en un sitio es la presencia de voice_assets_path.
Lo que solicito son dos booleanos públicos, sin credenciales, para que un cliente pueda decidir si mostrar el audio antes de obtener las salas. Ambos se derivan de un estado existente y no requieren un nuevo punto de acceso, en plugins/voice/plugin.rb:
En la línea 141, por encima de voice_public_access:
#Señales públicas, sin credenciales, para los clientes de la API de que el audio está habilitado.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
En la línea 152, por encima de voice_livekit_per_room_available:
# Si las uniones pueden usar LiveKit en absoluto. Una simple respuesta sí/no: sin URL, clave o
# valor de política. El atributo por sala siguiente solo controla la casilla de verificación SFU del
# formulario de la sala, y se lee como falso bajo la política all_rooms.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end
Esto no expone nada nuevo: expected_transport es un atributo sin control en RoomSerializer (línea 30, definido en la 150) y rooms#index omite el inicio de sesión (rooms_controller.rb:18), por lo que “livekit” / “mesh” ya es legible de forma anónima por sala. Esto simplemente responde a la pregunta sin una solicitud de sala que podría regresar vacía.
Por favor, no menciones a los miembros del equipo en bloque de esa manera (he editado y eliminado las menciones).
Puede ayudar si describes cuál es tu objetivo final con esta información adicional. Es difícil responder a una solicitud de funcionalidad sin ninguna justificación sobre para qué vas a utilizar la información.
Mis disculpas por haber hecho una pregunta en un anuncio y haber sido derivado a soporte, lo cual me dejó sin saber a quién dirigirme, ya que se trata de una solicitud de función y no de una incidencia técnica. Después de revisar durante las últimas 5 horas, etiqueté a los miembros responsables del commit/merge principal de voice.
Sin embargo, para dar algo de contexto: tengo una aplicación que actúa como cliente multiplataforma para comunidades de Discourse, cada una configurada de manera diferente, por lo que al inicio construye la navegación para el sitio en el que se encuentre el usuario. El chat aparece si está habilitado, y me gustaría que voice apareciera si está habilitado y realmente se puede unificar desde la aplicación.
La aplicación se conecta a través de LiveKit y no puede usar malla, por lo que en un sitio con malla prefiero omitir por completo voice de la navegación, en lugar de mostrar salas que fallarán al conectar y dar la impresión de que la aplicación está rota.
Así que el flujo es: leer la información del sitio una vez al inicio, decidir si voice pertenece a la aplicación para ese sitio y, luego, usar expected_transport por sala una vez que el usuario la abra. Los dos booleanos son solo el primer paso, y sin ellos estoy mostrando una función que no puede funcionar u ocultando una que sí puede.
Alternativamente, puedo colocar “No disponible en este foro” en una alerta global dentro de la aplicación, independientemente de si está habilitado o no, pero esto parecía el mejor enfoque, así que he identificado el punto de entrada y he proporcionado el código y los comentarios.
¡Gracias por la explicación! La solicitud tiene sentido.
El plugin de voz es nuevo y está en un estado experimental. Es probable que experimente cambios en las próximas semanas y meses. Especialmente cambios internos. Estamos abiertos a exponer esta información de alguna manera, pero aún no podemos estar seguros de cuál será su forma. Depende de cómo evolucione la integración de LiveKit.
Creo que te has malinterpretado, estuve despierto de la 1 a las 5 de la mañana revisando lo que se había hecho y las fusiones, y así es como encontré a los miembros del equipo a los que mencioné originalmente. No que esté esperando una respuesta durante 5 horas. La aplicación ya fue enviada para revisión y está utilizando el sistema predeterminado que ya tengo.
Eso está bien para mí, tómate todo el tiempo que necesites. He realizado mis pruebas durante un período de 6 meses, tomó algo de ajuste fino para la escalabilidad.