[Tsp-devel] Re: Un peu de refactoring dans JTSP ?

[Eric NOULARD]

Le samedi 12 mars 2005 à 02:39 -0500, Stephane Galles a écrit :
> Eric,
> 
> Je voulais commencer à écrire le jcdfwriter, mais j'aimerai simplifier
> un peu l'API publique du JTSP, en particulier, je souhaiterais
> - Masquer l'existence du session_id, vu depuis l'exterieur

Le Session Id est un peut 'artificiel' et pourrait même dégager
si tu trouves un moyen sympathique pour un consumer de retrouver
les différentes sessions qu'il a ouverte.
Attention toutefois au fait qu'un même provider peut avoir
2 sessions ouverte vers le même provider, c'est-à-dire 
que l'URL n'est pas une clef unique (par exemple pour utiliser
comme clef de la map) qu'on pourrait utiliser à la place de l'ID.


> - Masquer l'existence du channel_id, vu depuis l'exterieur

Je ne sais pas si masquer le channel 'id' est une bonne idée pour l'API
JTSP car celà correspond à des éléments de specs, que je trouvait
intéressant de retrouver dans l'API.
En tout cas si tu le masques mon avis serait qu'il faut 
pouvoir y accéder simplement 
avec un 'getter' sur l'objet concerné (?a priori la session?)

TspSession maSession.getChannelId();


> - Masquer les structures RPC, vu depuis l'exterieur

Oui ça sans pb c'est une bonne chose de masquer les structures RPC
notamment pour simplifier l'accès au TspRequestSample et
TspAnswerSampler.
J'avais d'ailleurs essayé de le faire (sans aller jusqu'au bout)
pour qu'un consumer ne voient que l'API du TspConsumer.

D'ailleurs si tu regardes le code de jstdout actuel on y est presque
sauf le new TSP_sample_symbol_info_list_t() qui pourrait largement
être éviter.


> 
> Puis - je faire apporter ces quelques modifs ? (of course, je modifie 
> jstdout et
> le plugin jsynoptic dans ce cas). Puis je ferai le jcdwriter.

Moyennant mes remarques ci-dessus tu peux y aller, notes que
mes remarques n'exprime que mon avis donc concernant le channel ID
peux-tu me donner une bonne raison de le cacher?

[a noter que ces Id sont de bêtes entier et pas des classes
 car j'avais un peu peur du nombre de 'petits' objets à trimbaler
 en en faisant des objets TspSessionID]

> 
> Accessoirement, je souhaiterai modifier un peu plus de manière à ce que :
> - Cela ne parle plus de socket dans le TspSession

Pourquoi pas tu ferais quoi?
Passer la TspAnswerSampleInit en argument du TspDataInputStream?
genre:

tspStreamReader = 
new TspStreamReader(new TspDataInputStream(asi), groups, sampleFifo);

> - Cela ne parle plus de structures RPC dans le TspSession

Pourquoi pas mais je pense que tu le ferais peut-être "mieux"
au moment d'introduire autre chose que RPC (CORBA, XML-RPC...)
à toi de voir.

> - On enlève les Sleep(1000) là ou c'est possible en les remplaçant par 
> des wait/notify

Yes bien sûr, d'ailleurs dans le même ordre d'idée aujourd'hui
on n'a pas d'API pour contrôler la priorité des threads crées
par jtsp (c'est également le cas en C) et j'ai le sentiment
que ça peut manquer....

> - Comme déjà discuté, je regarde si le package de Doug Lea pourrait etre 
> utile pour
> les accés concurrents

Bien sur d'autant que si je me souviens bien on l'aura direct en JDK1.5.

> - Renommer quelques fonctions et variables pour respecter les standards 
> de codage
> Java

Ben oui les '_' ma_belle_variable --> maBelleVariable 
je suis d'accord, j'ai fais bien trop de 'syntaxe' C en Java.

> 
> Je ferait cela dans un 2éme temps si j'ai ton accord

Pas de pb en ce qui me concerne.

> 
> Steph
> 

PS: j'arrive pas à accéder à Savannah depuis un moment ils sont Off?