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

[Stephane Galles]

OK, merci pour ces réponses super complètes.

Le présent email sera simplement un petit email pour ajouter
une ou deux petites idées suite à tes réponses. Je ne voulais
pas tout mettre dans le 1er email, parceque j'attendais de voir
la direction qu'allaient prendre tes réponses.

Je ferai un autre email concernant le sessionId, car cela ne concerne
que l'objet TspConsumer (le débat sur le n/n-1 concerne plutot
le TspSession)

En attendant, pour ne pas te mettre la pression sur ta description
d'API,  je commence plutot à coder traquillement mon writer CDF,
je le modifierai en fonction des modif de l'API. Cela nous permettra
de penser à l'API tranquillement.

Sinon, donc, voir mes petits commentaires ci - dessous

Je comprend mieux

Eric NOULARD wrote:

> Je vais faire une réponse courte puis une longue
> entrelacée avec tes commentaires.
>
> Oui l'API Java est imparfaite et j'ai effectivement
> essayé d'avoir l'API n-1 C, en mieux :)) 
> Mais cette tentative n'est pas abouti d'où tes remarques justifiée.
>
> Oui l'API C 'n' ne me plait pas sur l'aspect masquage/encapsulation
> sauf que c'est seulement
> au bout d'un certain temps d'utilisation qu'on peut le formuler
> plus clairement je n'avais pas d'argument valable à l'époque
> où tu l'as fait.
> En gros:  
>    - les void* nous embêtes parfois (mais ça tu l'as dis toi-même
>      y'a un moment.
>    - l'API n-1 i.e. proche des élèments de specs me manque
>      parfois.
>      Un exemple simple est d'essayer de coder un consumer
>      (utilisant l'API n-a) qui enregistrerait:
>           - la conf de sample (.i.e request_sample
>             ET answer_sample voir seulement l'answer_sample)
>             dans un fichier, aller disons XML
>           - le flux XDR en brut dans un second fichier
>      C'est pénible à faire car tu n'as pas accès:
>        - request_sample/answer_sample 
>          (ou a une API permettant de la manipuler)
>        - tu n'as pas accès à la socket sur laquelle tu souhaiterais
>          faire qqchose d'extrêment crétin à savoir copier TOUT
>          ce qui y passe dans un fichier :))
>
> En résumé je pense que mon API idéale serait une API n
> manipulant des objets (Java/C++) / structure (C) de niveau n-1
> sur lesquels on a des getters (mais a priori pas de setter)
> pour avoir directement accès aux élèments de spec SI NECESSAIRE.
>
> C'est ce que j'ai essayé de faire dans l'API Java initiale
> et c'est raté pour certains trucs mais j'y reviendrais après.
> Toutefois c'est certainement pour ça qu'elle te paraît louche :))
>
>   
>  
Je comprend. Il est vrai que comme je ne participe plus aux développements
de la partie C, et comme il n'y a pas eu de discussion concernant la 
forme de
l'API sur tsp-devel je ne connait pas le retour d'expérience sur l'API C 
(depuis
qu'elle a été utilisée sur de vrais projets) . C'est pour cela que ta 
remarque sur
le channel_id m'a interpelé car il  me manquait le contexte pour comprendre.

Pour la partie Java, no offense, je sais bien que c'étais le 1er jet, et 
que cela n'avait
pratiquement pas évolué depuis. Pour la partie C, l'API a évolué 
beaucoup plus,
a été raffinée, et même là il y a plusieurs trucs qui ne vont pas... 
Donc, vu comme
cela, ton API Java n'est pas si louche.

> Le samedi 12 mars 2005 à 19:35 -0500, Stephane Galles a écrit :
>  
>
> > OK, j'ai quelques questions concernant ta réponse sur le
> > channel_id, car cela soulève quelques interrogations
> > assez fondamentales dans mon petit cerveau fatigué
> > (c'est pour cela que je garde les autres problèmes
> > pour plus tard, comme le sessionId, pour lequel j'ai deux
> > ou trois trucs à raconter). Cela remet en effet un peu en question
> > ma vision de ce que doit être la lib consumer.
> >
> > Je te cite :
> >
> >    
> >
> > >   
> > > 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();
> > >
> > >
> > >
> > >      
> > Je comprends ton inquiétude par rapport à la spec, mais
> > à la fois je suis un peu perplexe car on ne s'est pas posé
> > vraiment la question de cette manière pour l'API C
> >    
>
> Je pense qu'on (en tout cas JE) n'était pas en mesure de
> se poser ce genre de question. Et pis une remise en question
> tous les 3/4 ans c'est pas mal :))
>
>  
OK, tout a fait d'accord pour la remise en question. C'est simplement
comme je disais ci - dessus, que je ne savais pas que ces remises
en question avaient commencé a apparaître depuis.
Bien sur, le retour d'expérience y'a qu'ça d'vrai.

> > Je te donne la compréhension que j'ai du statut de la spec par
> > rapport à l'API, et tu me dis quand je m'égare :
> >
> > La spec de TSP est là pour décrire comment implémenter
> > la lib TSP qui propose une API de haut niveau utilisable plus facilement.
> > La spec n'est pas là pour que les gens code un consumer ou un provider.
> > Pour cela ils prendront la doc de l'API, pas la doc de TSP (même si la
> > doc de TSP sera sûrement le meilleur endroit pour voir les concepts)
> >    
>
> Oui très juste la spec indique les concepts et DETAILLE les choses
> permettant la compatibilité entre +ieurs implem',
> notamment la tronche exacte de ce qui passe sur la socket.
> Ce qui n'est pas bien fait dans la spec, et il est aussi temps de
> re-écrire la specs mais bon c'est un boulot que je n'ai pas le temps
> de faire en ce moment et peu de personne peuvent le faire
> aujourd'hui à part toi, Yves, Robert ou moi-même :))
>
>  
>
> > Si la personne qui veut coder un provider doit connaître tous les détails
> > techniques de la spec TSP, cela limite un peu l'intêret d'une lib qui est
> > sensée encapsuler ce qui est encapsulable sans perdre trop de contrôle.
> >    
>
> Exact simplicité mais CONTROLE TOTAL si nécessaire:
>
> - controler les threads (c'est pas de la spec mais c'est nécessaire en
> tout cas en C)
> - accèder au contenu brut de la socket (ex enregistreur XDR)
> - examiner/inspecter le contenu d'un élément de spec
>  answer_sample, request_sample, request_xxx
>  de façon à pouvoir se référer à la SPEC si besoin. 
>   Et ceci même si il suffit d'avoir un AnswerSample.isOK()
>   plutôt que TspSpecConstant.ANSWER_OK = AnswerSample.getStatus();
>  Sauf que la dernière API est NECESSAIRE si on veut pouvoir 
>  sauver l'AsnwerSample dans un fichier pour lequel la specs ne dit
>  pas comment le faire.
>  Si on spécifiait comment on doit sauver une AnswerSample au format  
>  XML on pourrait alors avoir  AnswerSample.write(XDRStream)
>  Mais ça n'arrivera pas ou pas tout de suite. 
>  
C'est parfaitement clair.

>  
>
> > Cela n'empêche pas que la spec de l'API sera alors sans doute une extraction
> > de la spec de TSP, mais sûrement plus simple. En particulier cela enlèvera
> > toute la partie spec des artefacts techniques.
> >    
>
> La spec de l'API doit être simple et conviviale au niveau 'n'
> et [très] proche de la specs au niveau 'n-1'.
>
> MAIS EFFECTIVEMENT et tu as raison l'API n-1 ne doit pas être NECESSAIRE
> à celui qui utilise la 'n'. [evidemment le code même de la 'n' utilise
> 'n-1'].
>
>  
En fait, bien que cela n'apparaisse pas dans mes questions, je me 
doutais que tu
voulais avoir accés aux deux API. je n'en ai pas parlé pour ne pas 
alourdir mon
email précédent mais j'avais failli proposer la chose suivante :
- L'API n-1 pourrait être dans le package tsp.core.consumer  (donc dans 
jtsp.jar)
- L'API n (qui est un "Decorator" de n) pourrait être dans le package 
tsp.consumer.util
(donc dans tsp-tools.jar)
Mais les réponses que tu m'a données, semblent dire que n et n-1 vont 
être dans core.

> > La preuve : regarde l'API C actuelle, on y parle pas de channel_id ! Il
> > est pris en charge à 100%
> > C'est pour une bonne raison : c'est un numéro de session, il a une raison
> > technique d'être là dans une spec de protocole, mais à partir du moment où pour
> > une API je l'abstrait via un pointeur sur un objet ou un structure,
> > l'utilisateur de l'API n'a plus besoin de connaître son existence.
> >    
>
> Ben c'est là que le 'tout' encapsuler sans le décapsuleur me déplait
> et surtout devient génant pour coder certains trucs.
>  
OK, c'est clair qu'il y a pleins de cas d'utilisation dont je ne connait 
pas l'existence

>  
>
> > Paradoxalement l'API Java actuelle expose bien plus le protocole que la partie 
> > C.
> > (on montre le channel_id) Je ne dit pas que c'est bien ou pas bien,
> > je cherche juste à savoir pourquoi on ne veut pas le même niveau
> > d'abstraction coté C et Java (ta réponse sera alors peut être qu'il
> > faut changer la partie C !  :)  )
> >    
>
> Y'a un peu de ça :))
>  
:)

>  
>
> > De plus, on dirait que l'API Java essaie de ressembler en même temps à
> > la dernière et à l'avant dernière couche de la lib consumer C,
> > sans vraiment se positionner.
> >    
>
> Et c'est là que j'ai échoué et que tu vas réussir...
> Si pour une fois les erreurs des uns pouvaient servir aux autres :))
>
>  
Encore une fois, il n'y a eu qu'une seule itération sur l'API Java, cela
aurait été suprenant que cela soit parfait du 1er coup.
Et puis quitte à faire un peu de philosophie, je place ma citation
préférée : "l'expérience, ce n'est pas ce qui nous arrive ; c'est
ce qu'on fait de ce qui nous arrive". C'est tellement vrai en informatique !

> > En voulant encapsuler des choses, mais tout en les montrant,
> > on arrive a des choses étranges comme le code suivante,
> > qui vient de jstdout :
> >
> > TspRequestSample rqs =
> >                new TspRequestSample(
> >                    mySession.answerOpen.theAnswer.version_id,
> >                    mySession.answerOpen.theAnswer.channel_id,
> >                    fw,
> >                    1,
> >                    new TSP_sample_symbol_info_list_t());
> >
> >            rqs.setTspSSIArray(sampleSymbols.toTspSSIArray());
> >            /* send the requestSample */
> >            mySession.requestSample(rqs);
> >
> > Ici, on construit un objet TspRequestSample pour le passer à l'objet
> > mySession, en demandant à l'objet mySession les données pour le construire
> > (ex : channel_id que l'objet mySession connaît déjà), alors que
> > le channel_id aurait pu ne jamais sortir de mySession et cela aurait été
> > plus simple pour l'utilisateur de l API. Idem pour la version. (de plus, en
> > OOP ce n'est généralement pas trés bien de demander un attribut à un objet
> > pour lui piquer son boulot ; l'objet voleur devient moins cohésif)
> >    
>
> Yes c'est très moche cet appel et je fais un mail bientôt
> qui décrit mon idéal mais je dois partir sous peu en ballade sous
> le soleil Lauragais :))
>
>  
Prends ton temps ! Cela ne me bloque pas pour le CDFWriter.

> > IMHO, si on veux vraiment et réellement exposer le protocole tel que dans
> > la spec TSP, y compris le channel_id, dans ce cas il faut sortir ces données
> > du TspSession. L'objet TspSession doit donc devenir un Service (donc stateless).
> > Il a simplement une ref sur le canal de commande et de donnée, et tu lui
> > injecte les structures TSP en prenant tout en charge. Mais dans ce cas cela
> > me fait plutôt penser à l'avant dernière couche de l'API C, mais pas à l'API 
> > publique
> > de la partie C.
> >
> > Autrement dit, je suis un peu perdu, et avant de pouvoir discuter plus en avant
> > je vais résumer mon affreux blabla par ces questions :
> >
> > - Est tu d'accord que dans sa forme actuelle l'API Java est un compromis
> > entre la couche n-1 et la couche n de la lib C, en essayant d'encapsuler 
> > des choses tous en les montrant. ?
> > - Qu'il va falloir choisir clairement si on veut une n ou une n-1, et faire la 
> > petite
> > modif en conséquence : 
> >   - Si c'est une couche n qu'on veut, la même que C, il va falloir prendre en charge
> >    le channel_id (mais je suis quand même OK pour l'exposer via un
> >    getter, ça fait pas de mal)
> >   - Si c'est une n-1 qu'on veut :
> >       - il faut que l'objet TspSession devienne un Service, on lui enlève
> >       les ref sur les structures TspAnswerOpen, etc...Mais dans ce cas les
> >       consumers vont être plus long à écrire.
> >       - Et dans ce cas, pourquoi ne veut - on pas la même chose en C où on a 
> >         actuellement une couche n (et pas n-1) ?
> >
> > Steph
> >    
>
> Je fais un mail d'exemple d'API bientôt mais en essence:
>
> 1 API 'n'   autonome et propre utilisant des API/Objets n-1 EN INTERNE
> 1 API 'n-1' proche de la spec muni d'un décapsuleur à élément de spec.
>
>
>  
Je te laisse penser à cela tranquillement, mais d'aprés ce que tu me 
dit, et quite
à anticiper sur ta réponse, j'ai l'impression suivante :

On risque d'avoir besoin de trois définitions différentes des structures 
de données TSP
(je parle des TspAnserOpen, TspAnswerSample, etc...). Actuellement on a 
2 des définitions
sur 3

Il faudrait trois paquets de structure TSP :

- Pour la couche de commande, les structures associé au Stub de chaque 
protocole (ce qu'on trouve
pour RPC actuellement et généré par RemoteTea). Donc, ça on l'a.
- Pour la couche n-1, ce sont les structures que l'on a déjà dans 
tsp.core.common, c'est à dire
les même structures de données que celles des structures de la couche 
commande, mais protocol-agnostique.
- Ce qu'il manque : les structures de la couche n : une simplification 
des structures de la couche n-1.
(sans doute à mettre dans un package genre tsp.core.consumer.data par 
exemple pour ne pas surcharger
tsp.core.consumer)

> Merci de tes questions claires on va pouvoir 
> construire un très beau jtsp :))
>
>
>  
J'adore ces discussions constructives !

> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>