Re: [Tsp-devel] TSP_consumer_XXX

[Erk]

Le 05/04/06, Stephane Galles<address@hidden> a écrit :
>
>

>
> 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)

Oui Ok je vois et c'est toujours un objectif même si personne ne s'est
encore pointé pour le faire.

> 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,

Je vois et tu as raison ça "pourrait" sembler comme ça mais en fait
il n'en est rien et ce même si on partage les structures dans NOS
implémentations en C des libs consumer/ provider.

Le seul "point de contact" c'est:

1) la specs des requêtes sur le canal asynchrone
2) la specs des paquest synchrones

D'ailleurs si on change les structures actuelles dans le code C
celà ne cassera pas l'implem' java.

(c'est différent pour Python et Perl à cause de la SWIGification).

 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 ?"

Donc aujourd'hui je peux tout à fait écrire une autre lib TSP consumer
en C qui est totalement indépendante de la notre.
D'ailleurs en le disant ça me donne des idées pour une libTSP v2

>
> (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.

En fait pour le produit je ne sais pas mais de mon point de vue c'est
surtout pour améliorer la compréhension des libs pour les développeurs
(moi y compris au départ) qui ont bien du mal à comprendre pourquoi
tel changement du côté provider est quasiment à reproduire à
l'identique côté consumer.

>
> [...]
>
> >>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)

Il y a des différences mais elle sont minimes et comme nous en sommes
à reporter les changements provider --> consumer ben les unifier n'est
pas un travail beaucoup plus important.

Merci de ta réponse rapide en tout cas.

--
Erk