Re: [certi-devel] UML et Question !

[Benoît Bréholée]

Valéry Raulet <address@hidden> writes:

> Le second paramètre de createFederationExecution, c'est-à-dire le nom
> du fichier fed n'est utilisé que pour vérifier qu'il suit la
> convention nomFederation.fed . Le rtig charge donc le fichier nommé
> comme précédemment. 

Dans la norme il n'est question que d'un « FED Designator », dans la
doc RTI-NG il s'agit bien du nom du fichier, et celui-ci peut-être
relatif (et considéré par rapport au répertoire courant) ou absolu.
En relatif ça fonctionne, ce qui manque à CERTI c'est sans doute la
possibilité de tenir compte d'un chemin en absolu, c'est-à-dir ne pas
tenir compte du chemin dans la comparaison entre nom et nom.fed.

> Ce qui sous-entend qu'il doit être lancé depuis le même répertoire
> que l'application.

Pas forcément, il suffit qu'il ait accès au bon fichier. Ca peut etre
un fichier différent physiquement, le nom ne sert qu'à indiquer lequel
prendre. Idéalement le RTIG devrait chercher ce fichier dans les
répertoires d'un FEDERATIONPATH ou d'un fichier de
configuration. Actuellement il ne fait que regarder dans son
répertoire courant.

> Est-ce qu'il ne serait pas plus judicieux de transmettre le fichier
> par socket directement au serveur rtig ?

Le problème c'est qu'il faut garder le comportement actuel, si on veut
fonctionner avec des références aux fédérations plutôt qu'avec des
fichiers. Or il y a un seul service, et une norme à suivre. Le premier
paramètre ne peut pas contenir plus. Le second contient une référence
à un fichier .fed que le RTIG va chercher parmi ses fédérations
possibles (je suis en train de rajouter le format .xml utilisé en
1516). Il faudrait donc une notation conservant le fonctionnement
actuel et indiquant qu'un fichier est à transmettre. Pourquoi pas si
tu vois une manière de faire ça. La norme n'indique rien pour ça, par
contre ce sera peut-être parmi les propositions de norme pour les
headers, je crois que le DMSO proposera quelque chose au prochain
SISO-SIW. Je pense que la solution actuelle peut encore durer quelques
mois (puisqu'on peut utiliser des fichiers physiquement différents) en
attendant de voir si cette proposition impose une manière de faire.

A mon avis ce qui manque le plus à CERTI sur ce point là pour
l'instant, c'est la possibilité de définir une liste de répertoires où
le RTIG ira chercher les fédérations.


Je change de sujet : concernant le problème de link avec std::list.
J'ai fait un test en appliquant #773 et en commentant quasiment
tout. Bien sûr ça compile. Si je décommente l'attribut de type list,
là le link ne passe plus. Pourtant tout se passe très bien avec
d'autres patches similaires. Ca indique un problème lié à la présence
de list, mais pas lié à un problème d'implémentation/accès d'une de
ses méthodes (puisque l'attribut est déclaré, mais toutes ses
utilisations sont commentées). Je me demande si ça ne vient pas de
conflits avec des variables/attributs mal nommés : dans cette classe
il reste un attribut nommé « Message », alors que Message est un nom
de classe. Ca passe avec gcc, et ça passe (sans list) avec le
compilateur de Sun, mais je suis déjà tombé sur des cas où ça posait
problème. J'ai vu qu'il restait un attribut nommé List dans une autre
classe. J'ai l'impression que ça peut venir d'un conflit de ce style,
dont la source peut finalement être assez éloignée (un nom dans une
autre classe). Je modifierai ceux que j'ai vus, si tu en trouves
indique moi où, ça ne peut pas faire de mal de leur redonner un nom
normal.


Benoit.