Re: [Tsp-devel] TSP_consumer_XXX

[Stephane Galles]

Erk wrote:
[...]

> > Du coup j'ai une question (plutôt pour Stephane Garibou et Yves)
> > pourquoi avons-nous définit des structures "spéciales"
> > côté consumer:
> >
> > TSP_consumer_symbol_info_t
> > TSP_consumer_symbol_requested_t
> > ...
> > et leur version "list"
> >
> > au lieu d'utiliser directement les
> > TSP_sample_symbol_info_t
> >
> > telle qu'on les retrouve côté provider?
> >
> >
> >    
Après avoir lu ta question la 1er réponse qui m'est venu en tête est:
"aucune idée, mais alors vraiment aucune".
Et puis tout bien réfléchi, j'ai trouvé je pense un semblant d'explication.
Cela vaut ce que cela vaut, je préviens tout de suite.

Il faut se remettre dans l'état d'esprit de l'époque : on cherchait à avoir
une 1er implémentation de TSP. Hors, un des nombreux points fort
de TSP que nous cherchions à montrer via cette 1er implémentation
est qu'il peut y avoir un découplage d'implémentation totale entre le 
provider
et le consumer.
Genre :
- monsieur X lit la spec consumer et écrit un consumerX
- monsieur Y lit la spec provider et écrit un providerY
- monsieur X et Y ne se sont jamais recontré, mais, leur providers peuvent
se parler (en gros, hein, bien sur)

Maintenant qu'on a des implémentation en python, perl, JAVA, cela nous 
paraît
évident, car on vit avec. Mais à l'époque c'est ce qu'on cherchait à 
prouver. Autrement
dit, nous devions jouer le rôle de monsieur X et monsieur Y en même 
temps. Hors,
en mettant les structures de données communes dans une librairie commune 
provider/consumer
il me semble qu'on aurait couplé de manière suspecte consumer et 
provider, en semblant
dire qu'il faut une librairie TSP consumer/provider, ce qui rajoute 
implicitement un autre
point de contact (pas architecturale, mais d'implémentation) dont on ne  
parle pas dans
la spec, Cela aurait peut être été un mauvais message pour un 
observateur extérieur, genre :

"Quoi ?! il faut que je me link avec leur lib sinon je ne peux pas 
écrire de consumer ?
la spec ne me suffit pas ?"

(en fait il y avait bien une lib commune, mais elle ne contenait que des 
fonctions utilitaires
génériques, non liées à TSP)

Néanmoins, maintenant, le couple consumer/provider en C semble devenir 
un produit
à part entière, et n'a plus la vocation de preuve de concept. Il paraît 
dont peut être logique
effectivement de factoriser ces structures communes.

[...]

> > DONC ma question est:
> >
> > POUR la suppression des TSP_consumer_XXX
> > ou
> > CONTRE
> >
> >
> >    
Je dirais POUR, si les structures sont exactement équivalentes (je n'ai 
pas regardé, mais
il n'est pas impossible que côté provider ou consumer, les structures 
ait été instrumentées
légèrement différement, ce qui pourrait obliger à un peu de travail pour 
les rendre identiques)