Re: [certi-devel] CERTI

[Benoît Bréholée]

Bonjour, une réponse partielle...

> J'aimerai réaliser les choses suivantes et je voudrai savoir si ça ne
> pose pas de problèmes :
> 
> * Modifier le programme de test pour qu'il soit plus orienté C++,
> éclater en plus de fonctions, modifier le style pour qu'il corresponde
> à celui du projet et passer en langue anglaise. Permettre de lui
> rajouter des fonctionnalités plus tard.

Il faut un programme très simple parmi les tests, donc le billard
reste tel qu'il est, à quelques nettoyages près éventuellement. Ce qui
n'empêche pas d'avoir un autre programme de test, pourquoi pas basé
sur le billard, plus orienté objet. En fait j'en ai déjà un, mais sans
doute un peu trop orienté objet. Je l'utilise pour avoir un programme
de test facilement modifiable, les détails de l'exécution pouvant être
choisis en ligne de commande (ex: pas d'affichage/X11/GTK, différents
timers, il y a la structure nécessaire pour choisir parmi différentes
classes contenant des comportements différents des objets locaux).

Je n'ai pas le temps de le maintenir, c'est pour ça qu'il n'a pas été
mis dans la release de CERTI. Il me sert juste quand le billard
"normal" n'est pas suffisant. Je te l'envoie séparément. Si tu
maintiens une application de ce style (ou celui-là si tu comptais
partir dans la même direction), on peut toujours l'ajouter parmi les
tests ou comme package séparé. Je regarde si j'ai une version qui
fonctionne et je te l'envoie.

> * Implémenter toutes les fonctions au niveau du RTIambassador et lever
> une exception au niveau du RTIA et tenir compte du tag dans les
> méthodes l'utilisant.

Tu veux dire terminer le RTIambassador (envoyer les messages vers le
RTIA) et lancer l'exception « service non implémenté » coté RTIA ?
Dans ce cas là bien sûr, ça va le sens de l'implémentation. Idem pour
les tags. Par contre, laisse la partie DDM du RTIambassador telle
qu'elle est, je suis en train de m'en occuper.

> * Je développe également des fonctions au niveau du RTIambassador
> permettant de modifier le modèle objet pendant l'exécution. Peut-on
> l'intégrer dans CERTI ? (c'est pas la norme)

Il faudrait prévoir un mécanisme pour les extensions. Par exemple,
avoir les extensions que tu proposes dans un autre fichier du
répertoire libRTI, et le compiler ou non en fonction d'un flag passé
au compilateur via le configure (un ./configure --with-ton-extension).
Idem dans le include.

Juste une chose, il faut que ce soit du compatible GPL, avec entete du
style de ce qu'on a actuellement pour CERTI : 

nom - description en moins d'une ligne
copyright année détenteur du copyright

This file is part of ... (CERTI-ton-extension / ton-extension tout
court, à toi de voir)

Puis les quelques paragraphes de la licence à placer en entete, en se
référant au nom que tu as donné.

Dis-moi déjà si quelque chose de ce style te convient. J'essaie
d'imaginer le cas où on se trouve face à plusieurs extensions, un
répertoire dédié est peut-être préférable... Je vais aussi me
renseigner pour avoir quelques conseils sur ce sujet...

> * Que fait-on de la classe List ?

Rien, elle n'est plus présente dans les Makefile.am, donc pas dans les
paquets créés. Je la supprimerai du CVS quand je serai sûr que plus
personne n'en a besoin (prochainement).

> * Parser lisp style et xml : est-ce qu'on garde les deux. La norme
> autorise t-elle maintenant les fichiers XML ?

Non en 1.3 c'est toujours le style lisp, le XML c'est pour 1516. Et
surtout pour le développement, puisque le parseur XML est plus souple
pour faire des ajouts, tester des extensions, etc.

Voilà, pour le reste (classe ObjectClass), on en reparle dès que tu as
un peu plus de détails ?

A+

-- 
Benoît Bréholée                                         address@hidden
CERTI - http://www.cert.fr/CERTI/