[Tsp-devel] TSP refactored needs TESTERS...

[Eric NOULARD]

Salut à tous,

Le refactoring avance à grand pas, enfin j'espère.
Je me suis donc mis au travail dans la branche:

br_TSP_0_6_5_REFACTOR_DEVEL

J'ai besoin d' (au moins) un testeur pour les modifs
que j'ai fait dans vxstub, vu que j'ai pas de vxworks sous la main...

J'aimerais aussi que quelqu'un me lance les autotests dans un
environnement [t]csh car chez moi je galère... je pense que je
vais ré-écrire ces scripts de test en sh ou perl ou python
(merci de me donner votre avis).
Je pencherais pour perl car assez portable et indépendant du shell.

Donc pour tester:

cvs co -r br_TSP_0_6_5_REFACTOR_DEVEL

et puis après c'est comme d'hab.


Ce qui est fait:
------------------
i) API orienté objet pour le GLU
   et modif qui en découle dans src/core/ctrl et src/core/ctrl_init

   l'API générique est décrite dans src/core/ctrl/glue_sserver.h
   les "méthodes par défaut" dans src/core/ctrl/glue_sserver.c

   du coup l'écriture d'un GLU est (encore) plus simple,
   je pense qu'on peut encore faire mieux mais là c'est déjà 
   sympathique.

ii) MAJ des providers:
      bb_provider   -> OK (dont amélioration perfo sur valid. symbol)
      stub          -> OK
      vxstub        -> A TESTER (je n'ai pas de moyen de le faire)
      res_reader    -> NOK reste (au moins) 1 BUG recalcitrant 
                       qui fait un core dump...
      rt_stub/bbrt_stub -> A TESTER
 

iii) Preparation du merge TSP_WRITE 
   en cours avec API OO pour le GLU.


Ce qui reste à faire: (hormis les tests provider incomplets)
---------------------

1) dégommer le bug res_reader 
2) merge TSP_WRITE avec prévision tsp_async_read (déjà prévu dans ooGLU)
3) ajout d'une requête tsp_request_simple_info
   cette requêtes ne renverra PAS la liste des symboles mais
   seulement les infos providers (nom, fréquence) et éventuellement 
   le nombre de symboles.
   Ceci afin d'éviter la mort réseau pour un provider à what millions
   de symboles.
4) isoler le core tsp des types RPC
5) inverser la logique d'appel (ça c'est pour Yves :)) )
6...1000) pas mal d'autre trucs.

J'aimerais revenir sur le trunk après avoir fait 

au pire  1) ou 2)
au mieux 3) 

et je compte faire le 4) sur le trunk directement (a voir).
comme vous le verrez y'a hum... quelques modifs.
Donc si je reviens sur le trunk avec tout ça je propose
de créer un tag de branche br_0_6_x sur le trunk actuel
afin de pouvoir éventuellement faire des patches dans cette
branche pour ceux qui désireraient rester en API GLU ancienne
formule.

Une fois revenu sur le trunk je creerai une 0_7_0 
qui sera notoirement incompatible (en terme d'API) avec
la branche 0_6_x.

J'attends vos retours et continue sur 1) et 2).
sauf si quelqu'un veux se taper le 1) à ma place...

Eric