Réunion du 12-03-2024

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.😉

Configuration

Configuration -- fichiers ini

• Si vous activez un module dans un fichier ini, vous devez aussi décommenter certaines choses ailleurs dans les fichiers ini, certaines personnes n'y font pas attention.
• Techniquement, on peut tout regrouper dans une seule configuration, c'est ce que fait le système de toute façon. Avec les includes, on peut inclure n'importe quel texte et il sera chargé et remplacé en fonction de ce qui a été chargé en dernier.
• Les fichiers ini sont fusionnés dans un ensemble de configurations, sauf pour le fichier regions.ini
• Commandes de console permettant de voir la configuration en cours :

config get [<section>] [<key>]
Synonyme de config show

config show [<section>] [<key>]
Affiche les informations de configuration
Si aucune section ni aucun champ ne sont spécifiés, toute la configuration actuelle est imprimée.
Si une section est donnée mais pas de champ, tous les champs de cette section sont affichés.

Base de données

Migration

Fonctionnement actuelle de la migration

• Actuellement, si une migration échoue, tout continue comme si rien ne s'était passé.Rien ne s'arrête, l'échec est simplement signalé, c'est le feu et l'oubli. La migration s'exécute et tous les messages des modules de la console masquent les erreurs en quelques secondes. Ainsi, certaines grilles fonctionnent avec une combinaison d'échec de migration (partielle) et du bricolage des tables.
• La migration n'est pas faite en transaction[1].

Chaîne de connexion à la BDD

• La validité de la chaîne de connexion est la seule chose qui lève une exception.
• S'il y a une erreur dans la chaîne de connexion ou si on tente de redémarrer la base de données alors qu'elle est toujours en cours d'exécution, l'arrêt n'est pas immédiat et certains modules tenteront de se connecter. La plupart des modules qui se connectent directement envoient du texte rouge, mais ne mettent pas fin à l'ensemble. Les modules qui ont des chaînes de connexion différentes pourraient ne pas lancer d'exceptions. Une gestion efficace de ce problème n'existe pas. Andrew Hellershanks a l’intention de se pencher sur la question.

Nouveau système de migration

• Vincent Sylvester a écrit un nouveau système qui migre chaque table plutôt que de partir de l'état des tables d'une version supposée. Pour le passage à une autre version, les tables présentes sont validées et les tables absentes sont directement créées, le schéma vérifie si la table a l'apparence voulue . Le plan est d'avoir un nouveau système qui stocke les informations de version dans les commentaires des tables pour chaque table et de les migrer et les valider à chaque étape.
• Le nouveau système vérifie si un fichier de migration existe pour modifier une table vers une nouvelle version. Il vérifie d'abord si la table n'est pas déjà à jour et applique ensuite la migration. La base de données devrait envoyer des codes d'erreur si la commande SQL échoue. Si le système obtient un code d'erreur, il se termine en indiquant à l'utilisateur qu'il doit corriger la table manuellement.
• Il faut comparer beaucoup de choses : les types de données, les dimensions, etc. (column_name,data_type,is_nullable,column_default,column_key,character_set_name,collation_name).
• Pour l'instant, Vincent Sylvester garde les anciennes données au cas où quelqu'un aurait encore besoin de les utiliser, après quoi la nouvelle migration prendra la relais. Elle se fera par table, par version, avec une validation après coup pour s'assurer que les tables sont conformes à ce à quoi elles devraient ressembler. Le principal point critique est de savoir s'il faut laisser l'ancien système en place ou faire l'effort de transformer les migrations existantes en migrations par table et utiliser le nouveau système pour tout.
• Le schéma est dans un fichier pour que ceux qui ont fait des changements dans les tables pour leur propre système puissent les éditer et faire en sorte que la validation réussisse.
• Vincent Sylvester aimerait connaître les avis/besoins des utilisateurs sur un choix qu'il a à faire :
  • Actuellement son code utilise l'ancienne migration puis utilise le nouveau système sur la migration.
  • Une autre possibilité serait d'utiliser directement le nouveau système sans passer par l'ancien.

Informations

Versions d'OpenSimulator

Les versions release

• Elles sont identifiées par le seul numéro de version.
• Release actuelle [2] :

OpenSim.0.9.2.2 Yeti release

• Release plus ancienne [3]

 OpenSim 0.9.1.0 Snail release

Versions de développement

• Elles ont besoin du hash du commit pour une identification complète.[4]
• Exemple de commit [5] avec hash = b70b5c07e3d0e32f28122be2b5e3d9d5c1f4b6a0. On prend les 10 premiers caractères (b70b5c07e3).
• Les versions sur Osgrid indique aussi une heure.
• Exemple de nom de version de développement :

OpenSim 0.9.3.0 Nessie Dev b70b5c07e3 : 2024-03-11 00:18:05 0000 (SIM-0.3/0.8)

• La version 0.9.3.0 est donc encore en développement. Osgrid est une grille de test et utilise les versions de développement d'OpenSim.[6]
• Pour les développeurs de viewer les cibles sont la dernière release et le master de développement.
• Comment trouver la version dev d'opensim : malheureusement git hash n'est pas facile à intégrer dans un code. Actuellement on recherche un fichier .version ou les données du repo git telles qu'elles sont présentes sur un clone normal. Osgrid utilise le fichier .version

Heure d'été

• N'oubliez pas que la semaine prochaine (19-03-2024) et la semaine suivante (26-03-2024) l'heure de la réunion passe à 11h00 pour l'Union Européenne. Ensuite l'heure de la réunion repassera à 12h00, heure normale, après le 31 mars.
• L'Amérique du Nord est passée à l'heure d'été le week-end dernier.

Viewers

Compatibilité des viewers avec les versions d'OpenSim

• Le protocole Linden Lab a ajouté quelques paramètres pour indiquer aux viewers les caractéristiques des régions, mais Linden Lab ne les maintient pas. Il devrait y avoir un flag pour PBR[7] par exemple.
• Le viewer peut aussi utiliser la présence de certaines capacités[8] par exemple pour détecter l' EEP par rapport à windlight.
• Le viewer doit cibler la version et le master dev. Pour tous les problèmes qui surviennent avec les anciennes versions d'OpenSim, le viewer devrait envoyer un message pour demander à l'utilisateur de mettre à jour leur matériel.

Source

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