Re: [Tsp-devel] Ruby 2 / Python 0

[Erk]

Le 20/06/06, Stephane GALLES<address@hidden> a écrit :
> Quelques questions :
> Erk wrote:
> > 1) integration des modifs multi-type etc.. dans jtsp + creation
> > version JTSP_0_8_0
> >    compatible de son homologue en C
>
> Est ce qu'il y a toujours un intéret pour l'API Simple de JTSP ?

Il y a un interet theorique et on s'en est servi 1 fois pour
apprendre TSP car c'est plus simple.

Maintenant suite a l'evolution multi-type on en a profite pour
degommer certaines cochonneries de l'API "complexe"
(notamment la hashtable des sessions dans l'objet consumer
comme ca openSession renvoit un objet TspSession et pas
un int sessionId sur lequel il fallait faire getSession
 ensuite on fait close() sur l'objet Session et pas
  close(id) sur l'objet consumer, la classe consumer a plutot
  une tronche de factory maintenant...)
qui font que la difference entre les 2 n'est plus aussi violente qu'avant.

> Si oui, est ce que tu veux que je modifie la partie "simple" pour suivre vos
> modifs actuelles ? (entre autre : modification du code CDF, +
> modification consumer simple multi provider + modification fichier XML
> de sampling) ?

Les modfis multi-types ont ete faites de telle facon que si un ancien
consumer TSP ne demande que des doubles ca doit continuer de fonctionner.

Les modifs d'API ont ete faite via refactoring eclipse + modifs manuelles
donc au minimum les sources compil'.
Toutefois on a pas fait de test sur tous les consumer (et c'est vrai
qu'il faudrait
qu'on fasse des tests Junit pour tout ca) notamment le CDFWriter n'a
pas ete teste.

Pour les modifs des fichiers XML de conf elles ont ete incorporees aux sources
donc les consumers qui les utilisent doivent s'en sortir sans trop de douleur.

Donc en resume je ne pense pas qu'il soit necessaire (pour l'instant)
de retravailler la-dessus sauf pour implementer des tests JUnit.

> Ou bien est ce qu'on laisse la partie "simple" en l'état
> et on attend un peu de voir ce qu'on veut en faire ?

Je suis plutot partisan de ca.

> >
> > 2) Coup de ;ain test + evol integration CMake avec Fred
> >    (et tout ceux qui veulent s'y mettre bien sur :)))
>
> Oui, qu'est ce qu'on peut faire pour aider ? Je dois avouer que je ne
> sais pas où en sont les developpements de cette partie.

Y'a une tache expres pour ca.
https://savannah.nongnu.org/task/?func=detailitem&item_id=5615
rajoutes-toi dans la liste des CC si tu veux la suivre plus facilement.

En gros ca fonctionne si tu as un cmake recent (> 2.4)
mais ce n'est pas encore dans le CVS.
Je n'ai pas encore regarder avec Fred si la conf CMake actuelle
fait "tout" ce que configure faisait.

> C'est
> essentiellement du test d'intégration sur diverses plateformes qui vous
> aiderait ? (ha ben tiens, je viens de voir que j'ai package cmake tout
> pret à être installé dans le repository de mon Ubuntu)

Oui des tests sur differentes plateforme/distrib
puis...
ajouter ce qui nous manquait avec configure

1) Generation de librairies dynamiques
     - pour faciliter la migration des applis sans recompil'
       suite a l'installation d'un nouveau TSP
     - prevoir architecture de plugins pour Targa.

2) Autotests avec CTests (AC)

3) Ce que fait le build.xml (dans arbo C) aujourd'hui
     a) creation tar/tar.bz2/tar.gz timestampe
     b) creation des rpms (binaires, source et doc API)
     c) generation doc API
         on devrait pouvoir faire 'make apidoc'
         au lieu de cd src/doxy; make

> >
> > 3) Integration definitive et support long terme XML-RPC
> >    cote provider.
> >    Ce qui pourrait passer par "l'industrialisation"
> >    du generateur IDL --> xxxx-RPC de Fred
>
> ( petite réflexion mineure au passage : quand le canal XML-RPC sera
> devenu comme le canal RPC un canal de 1er classe, il me semble que le
> consumer JAVA a tout intêret à passer alors par ce canal, le canal RPC
> pur dans le monde JAVA devenant alors légèrement anachronique il me semble)

Oui je comprends,
toutefois il serait interessant de pouvoir choisir...
au cas ou certains provider ne souhaitant pas inclure un serveur http
preferent l'ONC-RPC.

En plus RemoteTea marche assez bien et reste 100% java.
Ce qui m'ennuie le plus avec le RPC c'est pas que ce soit vieux c'est que
c'est pas dispo sur etagere dans les langages de script.

Toutefois l'ONC-RPC ne va probablement pas disparaitre tout de suite
et en tout cas il faudra attendre la mort de NFS :)).

En gros je n'ai rien contre le fait que l'XML-RPC soit le canal par defaut
des consumers java mais pour l'instant le RPC en java ne nous derange pas
tant que ca.

Donc je serais plutot pour ajouter une option de config de la lib tsp consumer
en Java qui permettrait de choisir le canal par defaut. En sachant que
de toute facon si l'utilisateur choisit une URL TSP du genre:

rpc://mon_provider

ben on devrait faire de l'ONC RPC et pas XML-RPC.

Je vais aussi essayer de faire un mail qui resume ce qu'il
y a en cours et la ou je pense qu'on devrait aller de facon
a ce que chacun puisse se mettre a travailler sur la partie qui
l'interesse.

--
Erk