Re: [Tsp-devel] JTSP : Quelques nouveautés

[Eric NOULARD]

Ouh la la que du bon ce dimanche pour TSP.

Je ne commente pas la pléthore de fonctionnalités ajoutées
vu qu'elles me paraissent toutes très bien et justifiée
[et c'est pas parce que j'ai pas tout lu loin s'en faut]
Donc Caribou bas pour le prince [de] Galles (à ne pas confondre
avec celui qui vient d'épousailler sa Camilla :)).

Je jette quelques idées rapport aux questions de la fin à la fin.

Le dimanche 10 avril 2005 à 02:14 -0400, Stephane Galles a écrit :
> Bonjour,
> le JCDFWriter n'est pas encore codé mais il a déjà fait quelques petits...
> 
> En fait, j'ai codé avant les quelques couches d'abstraction qui me manquait
> pour faire le JCDFWriter, et tant qu'à faire, j'ai préféré coder ces couches
> pour qu'elles soient réutilisables. C'est pour cela que le JCDFWriter en 
> tant que
> tel n'est pas encore commencé  :)
> 
> Donc, sont apparus dans le CVS JTSP depuis quelques jours :
> 1) - tsp/core/consumer/simple : L'API consumer Simple
> 2) - tsp/consumer/util/aggregator : Une API consumer Aggregator 
> s'appuyant sur (1)
> 3) - tsp/util/xml/objmapper : des routines générique de chargement 
> d'objet à partir de fichiers XML
> 4) - tsp/consumer/util/configuration : Une 1er implémentation du 
> chargement des
> fichiers XML de sampling  s'appuyant sur (3)
> 5) - tsp/consumer/util/configuration/decorator : Une surcouche à (4) 
> pour aider au chargement
> des config de sampling pour initialiser (2)
> 
> Je vais détailler tout cela, mais je tiens à dire déjà que si les choix 
> des package ne conviennent pas,
> tout cela est évidemment modifiable à volonté.

[skiiik + miam]

Au passage j'ai mangé les 2 cerises et le gâteaux :))


> 
> Ces développement m'ont ammené à me poser deux questions sur la spec TSP
> - Dans le cas de l 'API Aggregator, comme les time_stamp des divers 
> providers
> ne sont pas synchronisés,il y a de fortes chances que du point de vue du 
> client
> de l'API, les timestamp des TspSamples qui sont récupérés jouent les 
> montagnes
> russes, genre : 0, 0, 0, 1, 0 , 1, 2, 1, 1, 1, 1, 2, 1, 2, 3, 3, 2, 3, 
> 3, 4 .... est ce que du point de vue de la
> spec c'est un problème ? 

Non je ne pense pas les timestamps TSP sont là pour ordonner les
sample au sein 
d'une unique session (connection socket provider<-->consumer).
Sur du multi-session y'a rien à faire.
D'ailleurs à mon sens l'API simple ne devrait pas exposer le timestamp
TSP. Au niveau 'N' on obtient un nouveau sample, si il vient d'un
Aggregator on peut vouloir demander à quelle session il appartient
guère plus.

L'aggregator devrait par contre pouvoir indiqué (si y'a demande)
de quelle session vient le sample. Mais là c'est peut-être le
boulot de l'API n-1.

On peut/pourrait se poser la question si l'Aggregator se 'transforme' 
en VRAI provider et qu'il offre une API TSP provider qui permette
le multiplexage réel des différents provider. Si c'était le cas
je l'appellerais Multiplexor et l'utilisateur du multiplexeur ferait
un "TSP open" avec l'URL TSP du multiplexeur et pas les 'n' URL
des différents providers (qui seraient fournis par le constructeur
du multiplexeur qui pourrait être le même utilisateur ou pas
d'ailleurs).



> Est ce qu'un client de l'API consumer doit 
> savoir gérer cela ? (le JCDFWriter
> le gérera bien sur, mais c'est pour savoir si la spec dit quelque chose 
> la dessus).

Je pense qu'on doit uniquement pouvoir vérifier à chaque nouveau sample
de quelle session il vient et c'est tout. 
De cette façon, dans le cas mono-session aucune vérif à faire.

[évidement on ne parle pas ici des samples 'spéciaux' qui doivent
 certainement être transformées en exception du genre:
  'sample perdu côté provider'
  'sample perdu côté consumer'
  ' socket brisée'...]

> - Ou en est la modification du provider C que Eric voulait faire pour 
> gérer le cas ou des symboles sont demandés,
> mais ou certains n'existent pas, et pour savoir quel étaient les 
> symboles erronés ? 

Ben elle est partiellement implémentée et sur mon disque.
Y'a peut de chance que je la finalise avant 2 semaines.
L'answer sample contiendra toujours la liste de TOUS les symboles
initialement contenus dans la request sample, le provider global
index des symboles inconnus sera positionné à -1 dans l'answer sample
reçue.

> C'est juste pour
> savoir comment le JCDFWriter devra réagir si le problème se pose.

Personnellement je prévois 2 comportements "génériques" au niveau
des applis consumers:

1) tolérants (c'est le cas de l'ascii_writer)
   Les symboles inconnus sont ignorés et simplement enlevés de la    
   request sample initiale qui est automatiquement retransmise.

2) stricte (c'est le cas de gdisp)
   Le consumer indique explicitement (stdout, pop-up etc...) la
   liste des symboles inconnus du provider.

> 
> Merci
> 
> Steph
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>