Re: RE : [Tsp-devel] Java : TSP-CDF-Writer

[Stephane Galles]

address@hidden wrote:

> Pour swing vs ligne de commande personnellement je dirais
> ligne de commande + IHM swing activable optionnellement...
> par la ligne de commande :))
>  
OK, mais j'ajouterai l'IHM dans un 2eme temps sans doute.
Chi va piano, va sano / allegro ma non troppo, tout ça quoi.

> Ce qui peut être intéressant dans l'IHM c'est les
> noms de fichiers, URL provider(s) etc... mais également
> la taille actualisée du fichier généré.
>  
Right. It makes sense. Mais pareil que ci - dessus, rapport
au piano.

> Si tu peux penser dès la conceptions à un writer 
> multi-provider c'est un plus forcément :))
>  
C'est marrant mais j'ai l'impression que la besoin de sampler des
en même temps des variables provenant de divers provider va être
tellement récurrent que je me demande si je ne vais pas ajouter cela
dans le Jcore plutot que dans chaque client. Et là j'ai l'impression que
ce n'est pas si simple que cela...

En particulier une règle métier doit être implémentée : comment
gère t'on le fait que les numéros de séquence de deux providers
différents peuvent être désynchronisés ? comment recalle - on les
numéros de séquence de deux providers ? Attend on des numéros de
séquence syncrones ? Utilise t'on un déphasage ? Utilise t'on une
variable Temps présente dans les deux providers? si oui quelle est
la règle de synchro ? Je suis perplexe :  on risque de créer des 
affichages ou des
fichiers d'enregistrement avec des symboles en parallèle mais qui sont
complétement déphasés (ne serait - ce qu'a cause des taille de buffer
différents des providers, même en imaginant que ceux - ci démarrent
en même temps)

> Sinon je vais essayer de m'exciter un peu pour le format
> XML pour les consumers, mais je peux rien promettre avant avril.
>  
Est ce que je peux partir avec ce que tu décrivais ici ? :
http://lists.nongnu.org/archive/html/tsp-devel/2004-10/msg00060.html
Cela permettra d'avoir un protype pour se faire les dents sur les 
fonctionnalités
que l'on veut vraiment. Surtout que je pense que je vais utiliser une 
bibliothéque
de mapping Objet/XML (genre Digester, Castor, JAXB, Xstream, etc...) 
donc je pourrait
modifier mon code trés vite en fonction de (tes remarques)/(des 
specs)/(des besoins)
et puis on se retrouve en mode Extreme Programming et donc Yves va avoir des
étoiles plein les yeux.

> En fait ce qui est "un peu" pénible c'estd'avoir
> une arborescence globale qui ne permette pas "simplement"
> de faire un checkout de certains modules séparemment.
>  
Pour les modules CVS, voire autre email

> En ce qui concerne jtsp, vu que maintenant c'est compile avec ant
> je préfèrerais:
>
> 1) créer un 
>    1 module jcore de haut niveau
>    1 module de haut niveau par consumer/provider tsp
>              jstdout
>              jsynoptic-plugins
>              jcdfwriter
>    1 module chapeau (alias CVS) qui regroupe tou ce beau monde
>      au bon endroit
>              jtsp 
>
> J'appelle module de haut niveau un module sur lequel on
> peut faire
>    cvs co <monmodule>
>
> Un module alias du genre
>    jtsp  jcore jstdout jsynoptic-plugins jcdfwriter
>
> ce qui fait que quand on fait 
>    cvs co jtsp
>
> on se retrouve avec une arbo propre:
>
>    jtsp/tsp/core/...
>    jtsp/tsp/consumer/jstdout
>    jtsp/tsp/consumer/jsynoptic-plugin
>    jtsp/tsp/consumer/jcdfwriter
>
> etc...
>
> Tout cela est faisable mais pour créer des modules
> CVS il faut demander aux gestionnaires Savannah car les fichiers
> du CVSROOT (celui de tsp s'entend) ne nous est PAS accessible 
> en écriture.
> Par contre on peut soumettre notre fichier module qu'ils controleront
> et installeront.
>
> A noter qu'on pourrait inclure jstdout dans jcore histoire
> que si on fait un checkout de jcore on ait au moins 1 consumer.
>
> Ca fait aussi que après ça si on veut jtsp + tsp C ben
> faudra faire 2 checkout à moins de créer un alias 
>
> tsp_all = tsp_all/tsp tsp_all/jtsp
>
> Personnellement je pense qu'on peut faire le test des modules
> CVS avec la partie java car c'est simple et au passage cela permettra
> de remettre les jstdout et autre jsynoptic à leur place.
> L'option ultime pour la partie java serait de créer un unique
> module de haut niveau: jtsp  qui regroupe tout, mais personnellement
> ça j'aimerais éviter.
>
> Votre avis?
>
> PS: sinon je suis tout à fait d'accord avec la remarque
>    de stéphane sur le nommage jcdfwriter devra être ancré
>    ou ill faut
>
>    jcdfwriter/tsp/consumer/jcdfwriter
>
> si il est pris séparemment et:
>
>    jtsp/tsp/consumer/jcdfwriter 
>
> sinon.
>
> Je salue la vivacité de notre Caribou :))
> A+
> Eric
>
> -------- Message d'origine--------
> De:     address@hidden de la part de
> Stephane Galles
> Date:   lun. 28/02/2005 07:33
> À:      tsp-devel
> Cc:     
> Objet:  [Tsp-devel] Java : TSP-CDF-Writer
> Bonjour, bonjour,
>
> Je suis sur le point de commencer un petit Consumer TSP en Java
> pour écrire des fichiers CDF, et je me demandais où je devais le placer
> dans l'arbo TSP ?
>
> J'avais pensé à src/consumers/jcdfwriter, mais les premières réactions
> semblent me dire que ce n'est pas la bonne place... Eric?
>
> Autre question : est ce qu'on veut que notre writer ait une interface en 
> swing ou
> simplement en ligne de commande ?
>
> Sinon, l'API du CDF en Java a l'air vraiment trés bien, mais j'ai eu une 
> petite surprise :
> ce n'est pas du Java pur, ce sont des appels JNI à la lib CDF native de 
> la plateforme.
> C'est pas grave, c'est sans doute mieux pour les perf et tant pis pour 
> la portabilité...
>
>
> En parlant d'emplacement dans l'arbo, une petite remarque un peu hors 
> contexte que
> je voulais faire depuis longtemps :
> Les deux projets jstdout et jsynoptic ne suivent pas une arborescence 
> standard, et c'est
> trés pénible avec les IDE qui ne comprennent plus ce qui se passe. Il 
> aurait fallu que les
> répertoires où sont placés les sources suivent le noms des packages. 
> Hors, pour jstdout
> il manque tsp/consumer et pour jsynoptic il manque 
> tsp/consumer/jsynoptic (voire par
> exemple le projet jcore qui lui a une bonne arbo). Simple remarque en 
> passant, mais
> si on commence de nouveaux projets Java, il ne faudrait pas reproduire 
> cela IMHO.
>
> Steph
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>
>
>