[Tsp-devel] TSP post-0.8.0: appel à contr ibution.

[Erk]

Salut à tous,

Après les livraisons des xTSP 0.8.0
voici un petit mail pour faire le point des travaux
en cours et à venir.
Je pense que ce serait pas mal d'organiser un tantinet
les responsabilités afin d'améliorer la gestion du code.

Mon but est:

0) DIre à tous les dév. un merci pour être arrivés
   ensemble jusqu'à la 0.8.0
1) De faire le point
2) Savoir qui peut prendre "officiellement" en charge telle ou telle tâche.


Merci de me dire si l'un ou l'une d'entre-vous souhaite prendre en charge
une des grandes lignes qui suit. On peut ensuite discuter ligne par ligne
d'une roadmap acceptable au regard du travail à accomplir et de
l'investissement en temps que chacun veut/peut y mettre.

A) Finir la gestion du multi-type & tableaux
   Le coeur TSP doit être OK mais certains/consumer/provider
   n'ont pas une gestion "complète" des tableaux.

    a) Gestion complète des tableaux
        Aujourd'hui si le symbol monTab
        est de dimension 3 on peut demander monTab (ascii_writer)
        mais pas monTab[1].
        En fait la request_sample permet de le faire mais
        la lecture du fichier de conf. ne gère pas "correctement'
        les xxxx[n].

    b) targa
        Gérer le multi-type et les tableaux.
        Visiblement vu le dernier mail d'Euskadi c'est en cours.

    c) tsp_gdisp
        Idem targa.

B) Utiliser libtspcfg.
   La libtspcfg a fait son apparition et permet de charger/sauver
   un fichier de config XML. J'aimerais que tous les consumers
   puisse utiliser ce format. Aujourd'hui seul l'ascii_writer peut le faire.
   C'est redondant avec le format de fichier XML de targa mais
   j'espère qu'on pourra discuter les avantages/inconvénients des 2
   formats pour converger vers un format unique.

C) AutoXXX --> CMAKE
   Fred a mis une première version en conf.
  Il restera encore du travail pour que ce soit utilisable
  comme avant et surtout permettre de générer les libs partagées
  (entre autre)
  Tant qu'on est pas tous d'accord pour le switch
  on laissera en conf les anciens makefile. Faudrait pas que ça dure trop
  longtemps car sinon ça va être pénible de maintenir les 2 fichiers.
  (Makefile et CMakeLists.txt)

D) XML-RPC
   La version actuelle fonctionne mais elle n'est pas compilée par défaut.
   Ce serait réellement utile que quelqu'un prenne ça en charge afin
   que l'XML-RPC soit compilé par defaut (côté provider)

   Une fois que c'est fait on pourra:
      D.1) mettre à jour rubytsp
      D.2) migrer perltsp et pytsp vers XML-RPC au lieu de Swig.

E) Générateur d'interface.
   Fred D. a commencé un générateur IDL --> ONC-RPC
                                                               --> XML-RPC
                                                                    ...
   L'idée est qu'on puisse générer un maximum de code
   à partir d'un IDL CORBA.
   On devrait pouvoir générer quasimeent toutes
    les fonctions actuellements codées à la main
   dans src/common.

   Genérer le tsp_rpc.x
   Générer les stub xml_rpc
   etc...
   Fred D a un très bon début de solution avec un parseur ANTLR (java).

F) Amélioration I/F GLU pour symboles dynamiques
   C'est un besoin récurrent. cf les mail d'Yves récents.

G) Module noyau linux pour export de valeurs de kernel via TSP.
    Fred D. y réfléchit sérieusement.

H) Gestion des releases TSP

    Pour l'instant je "gère" la sortie des versions pour le C et Java
    et les autres modules "vivent" leur vie sans gestion "réelle"
    des versions.

    H.1) TSP en C
    H.2) jTSP
    H.3) pytsp
    H.4) perltsp
    H.5) rubytsp

J) Prendre en charge la conception de ts2p.org

   J'ai ouvert et enregistré www.ts2p.org, histoire de garder le nom de domaine
   car www.tsp.org est déjà pris :(((.
   J'ai fait un premier jet de pages html minables. (www.ts2p.org/tsp)
    Fred D. en a fait un deuxième (www.ts2p.org)
   Aujourd'hui c'est en chantier mais ce serait cool
   d'avoir un site "opérationnel" même minimal.
   Je fournirais volontiers les accès au(x) volontaire(s).

--
Erk