Réunion du 26-03-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

osGetLinkInventoryKey

Changement de runprebuild.bat pour Windows

  • Git n'inclut plus par défaut System.Drawing.Common.dll pour Windows.
  • Maintenant, runprebuild.bat copie system_drawing également pour Windows [4]

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉


Scripts

osGetLinkInventoryKey

  • Cette fonction est apparentée à la fonction LSL llGetInventoryKey qui renvoie l'UUID de l'objet de l'inventaire à partir de son nom.
  • Prototype de la fonction osGetLinkInventoryKey déduit du code donc il faut peut être attendre la documentation sur le wiki 😉 :
key osGetLinkInventoryKey(integer linkNumber, string name, integer type);
  • Problème possible de la fonction SL llGetInventoryKey : plusieurs éléments de l'inventaire peuvent avoir le même nom mais, un type différent.
  • La fonction a été renommée deux fois. Au départ, Jeff Kelley l'a nommée osGetLinkInventoryAssetKey. Ubit Umarov l'a renommée osGetLinkInventoryItemAssetKey. Finalement, il l'a (re)renommée osGetLinkInventoryKey pour être cohérent avec le nom de la fonction llGetInventoryKey de LSL.

Problème de nommage des fonctions OSSL

  • Vincent Sylvester rappelle qu'Opensim doit suivre les spécifications de LSL au fur et à mesure qu'elles changent même si elles n'ont pas toujours de sens.
  • Problème de nommage des les fonctions OSSL en cohérence avec le nommage des fonctions LSL.
  • Solution envisagée par Vincent Sylvester : ajouter une surcharge de langage plus concise dans le shéma de nommage, en supprimants les préfixes "ll" et "os" dans les noms des fonctions et en les remplaçants par autre chose avec un nom de fonction logique. Mais, il ne pense pas que cela puisse être adopté partout et que tout le monde arrive à se mettre d'accord sur un schéma. L'ancien code pourrait rester en place, il suffirait d'ajouter un nouveau stub (morceau de code qui convertit les paramètres passés entre le client et le serveur lors d'un appel de procédure à distance [5] ) et de pointer vers l'ancien code.

Base de données

Système de migration

  • Nouvelle avancée : la version de la table est déterminée à partir des fichiers de schéma de version et les migrations sont appliquées en conséquence. Vincent Sylvester pense que c'est la solution la plus susceptible de fonctionner.
  • SQLite va nécessiter sa propre logique car il ne supporte pas information_schema [6](en).

PostgreSQL

  • Problème  : ne fonctionne pas localement pour le moment. Il n'y a personne pour le maintenir pour OpenSim. Sous Windows, impossible d'utiliser le plugin d'authentification et le connecteur utilisé ne fonctionne pas avec la dernière version sur GNU/Linux. Il serait bon de savoir si cela vaut la peine de le supporter à l'avenir , si quelqu'un l'utilise encore, ou si le temps ne serait pas mieux dépensé en améliorant MySQL/MariaDB.
  • Mantis 0008959 : Postgresql ne se charge pas, quelque chose avec un certificatecallback

MySQL/MariaDB

  • Ubit Umarov va peut-être remplacer le connecteur actuel par un connecteur opensource c'est à dire pas Oracle. Cela pourrait signifier la séparation MySQL/MariaDB ce qui ferait un moteur de base de données supplémentaire à maintenir. Le connecteur opensource (le nom ?) a été fait avec l'idée que MariaDB et MySQL d'Oracle sont différents.
  • Pour l'essentiel, les deux systèmes de gestion de base de données sont toujours similaires, mais les deux ajoutent leur propre syntaxe et leurs propres fonctions. Tant qu'OpenSim respecte les règles de base de SQL, il ne devrait pas y avoir de problème.

Modules

Module de chat vocal

Chez Linden Lab

  • Linden Lab remplace Vivox par un service interne, construit autour des parties opensource de WEBRTC et de code propre à Linden Lab. Ils ont rendu public toutes les librairies opensource qu'ils utilisent. Les solutions opensource utilisées n'ont que des versions pour Linux, il n'y a pas de version pour Windows.
  • Ils ont trois types de serveurs audio : ceux de la voix spatiale par région, les serveurs "peer to peer" pour le chat, ceux des conversations pour le chat de groupe.
  • Les serveurs "peer to peer" semblent être un protocole STUN [7] ce ne sont pas de vrais p2p pour protéger les IP des utilisateurs.
  • Beq a partagé avec nous les informations qu'elle a obtenues de Linden Lab : Mantis 8899

Côté viewer

Naturellement, le code du viewer est sous licence GPL (logiciel libre / Richard Stallman)[8], donc les développeurs de viewers tiers l'auront. Ubit Umarov va attendre que les viewers opensim implémentent le nouveau chat vocal.

Côté serveur OpenSim

  • Pour OpenSim, côté serveur, il faut créer un nouveau module, pour la partie proxy. Le backend pourrait être difficile pour la partie audio spatiale car il n'est pas ouvert pour le moment. Le codec spatial pour le serveur audio est propre à Linden Lab. Ils sont encore en train de réfléchir s'ils vont le publier en opensource ou le garder fermé.
  • Autre problème à résoudre : comment faire fonctionner le codec avec le viewer une fois connecté.
  • Le coût de bons serveurs à faible latence sera un problème. Les serveurs en cloud sont un exemple d'utilisation pour les serveurs vocaux. La charge est imprévisible le nombre de serveurs nécessaires peut augmenter uniquement pendant les heures de pointe.
  • Ubit Umarov pense que même si OpenSim arrive à faire fonctionner la voice, les performances de Vivox ne pourront pas être atteintes.

Sécurité

  • Autre question : faut-il mettre le serveur WEBRTC dans OpenSim ou le garder comme un service à part entière. Il existe des arguments pour chaque solution.
  • WEBRTC sans SSL ajouterait des vulnérabilités c'est pourquoi Vincent Sylvester s'orienterait préférentiellement vers une approche de service autonome plutôt que de choisir d'intégrer le service à OpenSim. Ce serait un service par proxy (intermédiaire) sécurisé correctement.
  • Si OpenSim fonctionne comme un proxy pour la voix, c'est plus sûr et cela permet des personnalisations poussées. Le client ne reçoit que l'IP d'OpenSim et pas les autres IP.

Voir aussi

Informations

  • Changement d'heure la semaine prochaine sur l'Union Européenne.

Viewers

Sharpview

  • Il y a encore quelques problèmes de traversé de frontière de région avec un véhicule sur OpenSim. Parfois, des parties du véhicule disparaissent jusqu'au prochain croisement de régions, certaines mises à jour d'objets sont perdues.
  • Sharpview effectue une reconstruction complète chaque fois qu'un objet traverse des régions alors que Firestorm doit recopier les objets à partir de la simulation quittée. Joe Magarac signal que Sharpview fonctionne actuellement avec des données provisoires, elles seront bientôt plus fournies. Avec une bonne collecte de données du côté du serveur et utilisateur, les problèmes devraient être résolus dans ce domaine. Il aimerait aller jusqu'au bout de cette démarche.
  • Si les régions ne sont pas sur le même serveur, la latence accentuent les problèmes. En utilisant un délai réseau sur un système GNU/Linux pourrait simuler cet état. Sharpview permet au maximum 5 secondes d'échange de connexion et certains serveurs sont très lents.
  • Le nouveau Sharpview devrait sortir la semaine prochaine et devrait permettre de s'asseoir. D'autres personnes pourront le tester.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-26

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_26-03-2024&oldid=8338 »