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

[Stephane Galles]

Eric NOULARD wrote:
[...]

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

> [skiiik + miam]
>
> Au passage j'ai mangé les 2 cerises et le gâteaux :))
>
>  
Heureux que la recette t'ai plu !  :)

[...]

> 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.
>  
Taberouette ! mais tu a raison, c'est ça le vrai problème ! je n'aurais 
pas du
exposer le timestamp au niveau n ! A force de cotoyer ce timestamp
j'avais fini par ne plus voir qu'il ne sert qu'au niveau du protocole.
Super ! Je le sors de la couche n, on en parle plus ! Merci de m'avoir
ouvert les yeux !

> 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.
>  
Etant donné que via l'API Aggregator, les noms des symboles contiennent le
namespace, et que dans le requestSample Aggregator, le client a reçu 
l'index du symbole
il est toujours possible de réassocier un sample au nom du symbole, et 
donc au
namespace, et donc à la session. C'est ça que tu veux dire ? ( J'ai une 
classe
NamespaceHelper à qui tu fourni une structure TspSimpleSampleSymbolInfo
et qui te retourne directement le namespace trouvé dans le nom du symbole).

> 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).
>
>
>  
Effectivement, quand on aura un provider java, il sera trés facile de 
plugger
l'API Aggregator pour en faire un provider (Multiplexor donc !), et ce 
sera encore
plus élégant, puisque dans ce cas le consumer ne connait même pas comment
a été initialisé le Provider.
Dans ce cas, je ne sais pas si l'API aggregator aura
un intéret à être utilisée directement. Peut être pour gagner en perf 
alors ?
Pour éviter une nouvelle étape de encodage/socket/décodage ? A voir...

[...]

> 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'...]
>
>  
Oui, je pense qu'aprés le JCDFWriter je vais regarder entre autre la 
gestion des erreurs.
(D'ailleur n'hésite pas à m'indiquer si de ton point de vue il y a 
d'autres priorités sur la partie
JAVA).

> > - 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.
>
>  
Rien ne presse, dis moi simplement quand cela fonctionne pour que 
j'ajuste les API
Simple et Aggregator pour tenir compte de cette amélioration.

[...]

> 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.
>
>  
Rien à ajouter à cela.


Merci pour ton feedback

Stephane.