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

[TSP]

On avait déja reflechi au multi-provider avec euskady et bob, c'était pas
simple...
Surtout les recalages de tgemps + ou moins interpollés.
Faudra qu'on en cause quand j'aurais + de temps.


> -----Original Message-----
> From: Stephane Galles [mailto:address@hidden
> Sent: Tuesday, March 01, 2005 3:07 AM
> To: address@hidden; tsp-devel
> Subject: Re: RE : [Tsp-devel] Java : TSP-CDF-Writer
> 
> 
> 
> 
> 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
> >
> >
> >
> >
> >  
> >
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document