Aller au contenu

« Réunion du 05-03-2024 » et « Réunion du 26-03-2024 » : différence entre les pages

De OSWiki
(Différence entre les pages)
Page créée avec « = Changements du code de la semaine= * Courts changements de code **'''Encodage AES''' [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=ab4b690ffd633427a26b1aabeba2e6d69a5682a4], ** '''Correction du dernier patch''' : [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=97b03f76c795c1b70f51377d032ece7504bceff2] ** Correction de [http://opensimulator.org/mantis/view.php?id=9118 '''mantis 9118 : osGet/SetPrimitiveParams -régression'''][http://opensimul... »
 
Page créée avec « = Changements du code de la semaine= ===osGetLinkInventoryKey=== * Nouvelle fonction OSSL développée par '''Jeff Kelley''' [http://opensimulator.org/mantis/view.php?id=9119 Mantis 0009119] [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=1aa7bea608301021e8dc7c52779b14df5fe171d6][http://opensimulator.org/viewgit/?a=commit&p=opensim&h=7c63ff11509110398910df94cfe4b023b331c7e4][http://opensimulator.org/viewgit/?a=commit&p=opensim&h=782bad994446b473b33e8b32ae... »
 
Ligne 1 : Ligne 1 :
= Changements du code de la semaine=
= Changements du code de la semaine=
* Courts changements de code
===osGetLinkInventoryKey===
**'''Encodage AES''' [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=ab4b690ffd633427a26b1aabeba2e6d69a5682a4],
* Nouvelle fonction OSSL développée par '''Jeff Kelley''' [http://opensimulator.org/mantis/view.php?id=9119 Mantis 0009119] [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=1aa7bea608301021e8dc7c52779b14df5fe171d6][http://opensimulator.org/viewgit/?a=commit&p=opensim&h=7c63ff11509110398910df94cfe4b023b331c7e4][http://opensimulator.org/viewgit/?a=commit&p=opensim&h=782bad994446b473b33e8b32ae4954418c5270a8]  
** '''Correction du dernier patch''' : [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=97b03f76c795c1b70f51377d032ece7504bceff2]
* [[Réunion_du_26-03-2024#osGetLinkInventoryKey_2 | Plus d'informations au chapitre Script]]
** Correction de  [http://opensimulator.org/mantis/view.php?id=9118 '''mantis 9118 : osGet/SetPrimitiveParams -régression'''][http://opensimulator.org/viewgit/?a=commit&p=opensim&h=52c287d8dcbc8fa6e15753b6f16aa31ce294323f]
=== Changement de runprebuild.bat pour Windows ===
** Remplacement du nom de fonction osget*InventoryKey en osget*inventoryItemKey.
* Git n'inclut plus par défaut System.Drawing.Common.dll pour Windows.
** Ajout des fonctions osGetSitTargetPos(), osGetSitTargetRot() [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=d58f9f0f5d196e739b4b289b42bb9e488ecfc155] ( Auteur Jeff Kelley)
* Maintenant, runprebuild.bat copie system_drawing également pour Windows [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=4a8d4414bd158d9387dc4ada36f46d5440d9653f]


= Avertissement =
= Avertissement =
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
= Scripts=
= Scripts=
* La fonction [http://opensimulator.org/wiki/OsGetPrimitiveParams '''OsGetPrimitiveParams'''] a été corrigée.
===osGetLinkInventoryKey===
* La fonction '''osgetInventoryKey''' devient  [http://opensimulator.org/wiki/OsGetInventoryItemKey osgetinventoryItemKey] : la clé renvoyée est la clé de l'objet, pas la clé de l'asset comme avec la fonction [https://wiki.secondlife.com/wiki/LlGetInventoryKey LlGetInventoryKey].
* Cette fonction est apparentée à la fonction LSL [https://wiki.secondlife.com/wiki/LlGetInventoryKey/fr llGetInventoryKey] qui renvoie l'UUID de l'objet de  l'inventaire à partir de son nom.
* Ajout des fonctions  [http://opensimulator.org/wiki/OsGetSitTargetRot osGetSitTargetRot()] et [http://opensimulator.org/wiki/OsGetSitTargetPos osGetSitTargetPos()]
* 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.


= Archivage =
===Problème de nommage des fonctions OSSL ===
=== AOR : assignation des propriétaires et des créateurs ===
* 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.  
* '''Question''' : Comment les noms des créateurs Hypergrid sont-ils  trouvés au chargement d'un OAR ?
* Problème de nommage des les fonctions OSSL en cohérence avec le nommage des fonctions LSL.
* '''Réponse''' :  Le code actuel essaie de préserver le créateur. L'UUID et le nom du créateur et l'URL de sa grille d'origine sont sauvegardées dans l'OAR. C'est ce qui est nécessaire pour interroger un profil. Le chargement de l'OAR appelle la grille distante et obtient le nom de l'avatar. Seule la photo est récupérée avec quelques données de profil.
* 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 [https://fr.abcdef.wiki/wiki/Stub_%28distributed_computing%29] ) et de pointer vers l'ancien code.
* '''Question''' : Mais si l'OAR a été fait sur la grille où l'OAR est chargé, est-ce qu'il conserve aussi l'uuid, le nom et l'url de la grille ?
* '''Réponse''' : Cela devrait être ainsi mais, il est possible que localement ce ne soit pas le cas. Il est même  probable que pour le créateur local l'OAR ne stocke que l'UUID et donc quand un OAR est déplacé, les données ne correspondent pas à un compte local. Il y a aussi le cas des installations non hypergrid, dans ce cas, les OAR ne peuvent pas avoir toutes les informations sur le créateur.Les données des créateurs devraient être conservées et stockées pour chaque primitive, en théorie, on pourrait construire des objets avec des pièces créées par d'autres.
* '''Problème''' : La seule chose qui modifie les données du créateur est le paramètre home de la commande save oar, mais cela devrait tout stocker, donc peut-être que la fonction restore n'extrait pas les données correctement. À résoudre (TODO).
* '''Question''' : est-ce que de la même façon l'uuid et le nom du propriétaire et l'url de sa grille d'origine sont sauvegardés dans l'OAR.?
* '''Réponse''' : le propriétaire peut être remplacé. Les OAR sont conçus pour les sauvegardes, moins pour le partage.
* '''Propriété intellectuelle''' : le code peut donc être contourné, les options permettent de remplacer toutes les données originales du créateur ce qui est aussi faisable au niveau du serveur. Mais, les données d'un créateur d'objets liés sont cachées en XML dans le blob dans la base de données, ce n'est pas aussi simple à faire.  
* '''Informations complémentaires''' : aide sur les commandes  save OAR et load OAR
<pre>
save oar [-h|--home=<url>] [--noassets] [--publish] [--perm=<permissions>] [--all] [<chemin OAR>]
Sauvegarde les données d'une région dans une archive OAR.


-h|--home=<url> ajoute l'url du service de profil aux informations utilisateur enregistrées.
= Base de données =
--noassets empêche l'enregistrement des assets dans l'OAR.
===Système de migration ===
--publish enregistre un OAR dépourvu des informations relatives au propriétaire et au dernier propriétaire.
* '''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.
  Lors du rechargement, le propriétaire du domaine sera le propriétaire de tous les objets.
* '''SQLite''' va nécessiter sa propre logique car il ne supporte pas information_schema [https://en.wikipedia.org/wiki/Information_schema](en).
  Ceci est utile si vous mettez à disposition des OAR qui pourraient être rechargés sur la même grille que celle à partir de laquelle vous avez publié.
===PostgreSQL ===
--perm=<permissions> empêche les objets dont les permissions sont insuffisantes d'être enregistrés dans l'OAR.
* '''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.
  <permissions> peut contenir un ou plusieurs de ces caractères : "C" = Copier, "T" = Transférer
*[http://opensimulator.org/mantis/view.php?id=8959  Mantis 0008959] : Postgresql ne se charge pas, quelque chose avec un certificatecallback
--all enregistre toutes les régions du simulateur, au lieu de la région actuelle.
=== MySQL/MariaDB===
Le chemin OAR doit être un chemin de système de fichiers. S'il n'est pas indiqué, le fichier OAR est sauvegardé dans region.oar dans le répertoire courant.
* 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.  
</pre>
* 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.
<pre>
load oar [-m|--merge] [-s|--skip-assets] [--default-user "Nom d'utilisateur"] [--merge-terrain] [--merge-parcels] [--mergeReplaceObjects] [--no-objects] [--rotation degrés] [--bounding-origin "<x, y,z>"] [--bounding-size "<x,y,z>"] [--displacement "<x,y,z>"] [-d|--debug] [<Chemin OAR>]
Charge les données d'une région à partir d'une archive OAR.


--merge fusionne l'OAR avec la scène existante (supprime le chargement du terrain et des informations sur les parcelles).
= Modules =
Options avec --merge
=== Module de chat vocal ===
  --merge-terrain charge également le terrain, en remplaçant l'original
==== Chez Linden Lab ====
  --merge-parcels charge également les parcelles, en les fusionnant avec l'original
* 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.  
  --mergeReplaceObjects si la scène contient un objet avec le même identifiant, le remplace
* 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.
      sans cette option, le chargement de cet objet est ignoré
* Les serveurs "peer to peer" semblent être un protocole STUN [https://fr.wikipedia.org/wiki/Simple_Traversal_of_UDP_through_NATs] ce ne sont pas de vrais p2p pour protéger les IP des utilisateurs.
--skip-assets chargera l'OAR mais ignorera les assets qu'il contient.
* Beq a partagé avec nous les informations qu'elle a obtenues de Linden Lab : [http://opensimulator.org/mantis/view.php?id=8899 Mantis 8899]
--default-user utilisera cet utilisateur pour tous les objets ayant un propriétaire dont l'UUID n'est pas trouvé dans la grille.
--no-objets supprime l'ajout d'objets (bon pour charger uniquement le terrain).
--rotation spécifie la rotation à appliquer à l'aor . Spécifiée en degrés.
--bounding-origin ne place que les objets qui, après déplacement et rotation, se trouvent à l'intérieur du cube de délimitation dont la position commence à <x,y,z>. La valeur par défaut est <0,0,0>.
--bounding-size spécifie la taille du cube de délimitation. La valeur par défaut est la taille de la région de destination et ne peut être supérieure à celle-ci.
--displacement ajoute cette valeur à la position de chaque objet chargé.
--debug oblige l'archiveur à afficher des messages sur l'emplacement de chaque objet.


Le chemin peut être un emplacement du système de fichiers ou un URI.
==== Côté viewer ====
  S'il n'est pas indiqué, la commande recherche un OAR nommé region.oar dans le répertoire courant. [--rotation-center "<x,y,z>"] était une option, maintenant elle ne fait rien et sera bientôt supprimée. Lorsqu'un OAR est chargé, les opérations sont appliquées dans cet ordre :
Naturellement, le code du viewer  est sous licence GPL (logiciel libre / Richard Stallman)[https://fr.wikipedia.org/wiki/Licence_publique_g%C3%A9n%C3%A9rale_GNU], donc les développeurs de viewers tiers l'auront. Ubit Umarov va attendre que les viewers opensim implémentent le nouveau chat vocal.
1 : Rotation (autour du centre de la région de l'OAR entrant)
==== Côté serveur OpenSim ====
2 : Recadrage (un cube de délimitation avec origine et taille)
* 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é.
3 : Déplacement (définition des coordonnées de décalage dans la région de destination)
* Autre problème à résoudre : comment faire fonctionner le codec avec le viewer une fois connecté.
</pre>
* 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.


= Tests =
==== Sécurité ====
===Nouveaux  Xunit ===
* 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.
* Vincent.Sylvester pense que les tests s'exécuteront sur linux et qu'ils fonctionnent certainement très bien sur windows. Il ne peut pas tester sur Mac. Il va affiner cela dans les semaines à venir et écrire quelques tests.
* 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.


===vérification des migrations===
==== Voir aussi ====
* Il a terminé une routine de vérification des migrations qui vérifie les tables de la base de données existante par rapport à un bon schéma connu et qui pique une colère s'il y a divergence. Actuellement, la routine s'exécute à la fin de chaque migration. C'est une  vérification finale  qui test si tout est comme il se doit avant le démarrage.
* [[Réunion_du_19-03-2024#Chat_vocal |Même sujet développé pendant la réunion du 19 mars 2024]]
* C'est pour éviter qu'un problème de migration ne casse des choses et n'alerte l'utilisateur sur le fait qu'il doit peut-être corriger manuellement ses tables.
=Informations=
* Changement d'heure la semaine prochaine sur l'Union Européenne.
= Viewers=
= Viewers=
===Sharpview ===
=== Sharpview ===
* '''Nouvelle version disponible  pour Linux et Windows''' :  http://animats.com/sharpview/releases/release-0.6.0.html
* 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.
* Pour télécharger, nom d'utilisateur "'''devs'''", mot de passe "'''thread'''".
* 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.
* En cas de panne, envoyez un mail à "'''info@animats.com'''".
* 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.
* À utiliser avec un avatar léger. Cette version du viewer permet les passages entre deux régions mais, sur une simulation OpenSim récente comme les régions Ubittest (OpenSim 0.9.3.0 Nessie Dev 854f672 mardi 6 mars ) Ubittest2 d'Osgrid  ( OpenSim 0.9.3.0 Nessie Dev 0d73a81 mardi 6 mars).
* '''Le nouveau Sharpview devrait sortir la semaine prochaine''' et devrait permettre de s'asseoir. D'autres personnes pourront le tester.
* '''Joe Magarac''' est prêt à travailler pour rendre Sharpview compatible avec OpenSimulator. Mais il '''a besoin de savoir avec quelle version d'OpenSimulator son viewer doit être compatible'''. Actuellement, Sharpview ne supporte que les simulateurs affiliés à OSGrid, cela permet une certaine standardisation.
* '''Réponse''' : Si cela fonctionne avec '''les versions release et master dev''' et que les anciennes versions ne fonctionnent pas, c'est à l'administrateur de la région  d'y remédier. Les administrateurs d'Osgrid ont décidé de suivre le code des développeurs. Mais, il est possible que certains simulateurs 0.7 essaient encore de se connecter sur Osgrid.


= Source=
= Source=
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-05
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-26

Dernière version du 30 novembre 2024 à 15:51

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_05-03-2024&oldid=234 »