@Falco Est-il possible d’exposer un contrôle public dans les paramètres du site/sérialiseur indiquant si LiveKit est configuré, en plus de voice_enabled ?
Actuellement, voice_enabled est exposé au client, mais il n’y a pas de signal public indiquant si un site peut servir LiveKit. L’unique attribut de site lié à LiveKit, voice_livekit_per_room_available, est limité à la case à cocher du formulaire de salle, il renvoie donc false avec la politique all_rooms et ne peut pas être utilisé pour répondre à la question « ce site utilise-t-il LiveKit du tout ? ».
RoomSerializer#expected_transport couvre bien le cas par salle, mais cela nécessite d’abord de récupérer les salles, et il renvoie vide lorsque voice_public_access est désactivé, même sur un site où LiveKit est entièrement configuré.
Quelque chose comme ceci serait-il acceptable ? Il est dérivé de l’état existant, n’expose aucune information d’authentification ni détail de politique, et ne nécessite pas de nouveau point d’accès.
Cela irait dans plugins/voice/plugin.rb, après le bloc voice_livekit_per_room_available et juste avant la ligne Voice::DefaultRoomSeeder.ensure! :
# Signal public, sans informations d'authentification, indiquant que le site peut servir LiveKit. add_to_serializer(:site, :voice_livekit_available) do Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled" end
voice_enabled n’est pas accessible du tout via l’API JSON : /site.json ne contient aucune clé site_settings. Le seul signal public indiquant que la voix est active sur un site est donc la présence de voice_assets_path.
Ce que je demande, ce sont deux booléens publics, sans authentification, permettant à un client de déterminer s’il doit afficher la voix avant de récupérer les salles. Les deux sont dérivés de l’état existant et ne nécessitent pas de nouveau point d’entrée, dans plugins/voice/plugin.rb :
À la ligne 141, au-dessus de voice_public_access :
#Signaux publics, sans authentification, pour les clients API indiquant que la voix est activée.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
À la ligne 152, au-dessus de voice_livekit_per_room_available :
# Indique si les connexions peuvent utiliser LiveKit du tout. Une simple réponse oui/non : pas d'URL, de clé ou de valeur de politique. L'attribut par salle ci-dessous ne fait que contrôler la case à cocher SFU du formulaire de salle, et renvoie false sous la politique all_rooms.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end
Cela n’expose rien de nouveau : expected_transport est un attribut non restreint sur RoomSerializer (ligne 30, défini à la ligne 150) et rooms#index ignore la connexion (rooms_controller.rb:18), donc « livekit » / « mesh » est déjà lisible anonymement par salle. Cela répond simplement à cette question sans nécessiter de récupération de salle qui pourrait revenir vide.
Merci de ne pas mentionner les membres de l’équipe en bloc comme ça (j’ai retiré les mentions).
Il serait peut-être utile de décrire quel est votre objectif final pour ces informations supplémentaires. Il est difficile de répondre à une demande de fonctionnalité sans aucune justification quant à l’usage que vous comptez en faire.
Mes excuses, j’ai posé une question sur une annonce et j’ai été redirigé vers le support, ce qui m’a laissé dans l’incertitude quant à la personne à contacter, étant donné qu’il s’agit d’une demande de fonctionnalité plutôt que d’un dépannage. Après avoir passé les 5 dernières heures à examiner le sujet, j’ai étiqueté les membres responsables des principaux commits et fusions liés à la voix.
Cependant, pour ajouter un peu de contexte. J’ai une application qui agit comme un multi-client pour des communautés Discourse, chacune étant configurée différemment. Ainsi, au démarrage, elle construit la navigation du site sur lequel l’utilisateur se trouve. Le chat s’affiche si le chat est activé, et je souhaite que la voix s’affiche si la voix est activée et réellement accessible depuis l’application.
L’application se connecte via LiveKit et ne peut pas utiliser le mode mesh. Par conséquent, sur un site en mode mesh, je souhaite exclure la voix de la navigation plutôt que d’afficher des salles qui échoueraient à se connecter, ce qui donnerait l’impression que l’application est défectueuse.
Le flux est donc le suivant : lire les informations du site une fois au démarrage, décider si la voix doit faire partie de l’application pour ce site, puis utiliser expected_transport par salle une fois que l’utilisateur l’ouvre. Les deux booléens ne sont que la première étape, et sans eux, je risque soit d’afficher une fonctionnalité qui ne peut pas fonctionner, soit de masquer une fonctionnalité qui le peut.
À titre alternatif, je peux afficher « Non disponible sur ce forum » dans une alerte globale au sein de l’application, indépendamment de l’état d’activation, mais cette approche me semblait préférable. J’ai donc identifié le point d’entrée et fourni le code avec des commentaires.
Merci pour l’explication ! La demande est logique.
Le plugin vocal est nouveau et se trouve dans un état expérimental. Il subira probablement des modifications au cours des prochaines semaines et des prochains mois, en particulier au niveau interne. Nous sommes ouverts à l’idée d’exposer ces informations d’une manière ou d’une autre, mais nous ne pouvons pas encore déterminer sous quelle forme. Cela dépendra de l’évolution de l’intégration LiveKit.
Si vous pensez qu’attendre 5 heures est trop long, c’est que vous êtes peut-être nouveau dans le concept de communications asynchrones sur les forums. Bienvenue !
Je vais enquêter sur ce point et proposer une solution que nous pourrons utiliser.
Je pense que vous avez mal compris. J’étais éveillé de 1 h à 5 h du matin pour examiner ce qui avait été fait et les fusions, c’est ainsi que j’ai trouvé les membres de l’équipe que j’avais initialement mentionnés. Ce n’est pas que j’attends une réponse depuis 5 heures. L’application a déjà été soumise pour examen et elle utilise le système par défaut que je possède déjà.
C’est tout à fait correct pour moi, prenez autant de temps que nécessaire. J’ai effectué mes tests sur une période de 6 mois, il a fallu faire quelques ajustements fins pour la mise à l’échelle.