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

[Stephane Galles]

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

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

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

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


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

>