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

[Eric NOULARD]

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

   

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

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

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

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

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

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

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


Merci de tes questions claires on va pouvoir 
construire un très beau jtsp :))