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

[Eric.NOULARD]

Je suis d'accord avec vous tous.
Mon seul souci [aujourd'hui] quand je parle de
multi-provider c'est de pouvoir via le même fichier
de conf pouvoir "sampler" n symbols provenant de p providers.

Pour un écrivain fichiers (res, cdf, ...)
cela devrait [à mon avis] pour l'instant 'p' fichiers de sortie.
Ces 'p' fichiers pourront être consolidés plus tard, sauf que
c'est plus simple de faire comme ça que de lancer
'p' writer avec 'p' fichier de conf...

A noter qu'aujourd'hui avec Jsynoptic on peut déjà faire
du multi-provider à différentes fréquences et
tracer 'Y_provider1' en fonction de 'X_provider2'
et ça marche pas mal du tout.

C'est également vrai pour tsp_gdisp+.

Mon souci n'est pas de "corréler"/"recaler" les timestamps
de l'un ou de l'autre mais de récupérer des symboles
(donc des valeurs TSP et pas leur timestamp associés)
peu importe qu'une partie vienne d'afrique et l'autre du canada :))

A mon sens de toute façon la corrélation des providers TSP ne
peut-être faite que par des valeurs 'applicatives' par exemple
la valeur d'un symbole TSP particulier et pas via le timestamp
qui n'a d'existence que parce que TSP existe.
Si on veut un timestamp "fonctionnel" c'est aux provider
de publier un symbole de plus.

Mais j'ai peut-être raté qqchose?

En tout les cas je suis d'accord sur le fond, c'est pas pour
maintenant.

Quant à mettre dans jcore une classe qui permette d'ouvrir
un 'pool' de connexion TSP pourquoi pas? A toi de voir
la pertinence de ce truc Stephane.

Ce serait une classe contenant un tableau/liste
de TspSession mais avec des
méthodes qui 'agrègent' les appels en un seul appel
pour éviter les boucles répétitives?

De toute façon mon idée était de "penser" au multi-provider
pas forcément de l'implémenter hyper siouxement, sauf
si bien c'est un défi neuronal intéressant :))

J'attends encore une ou 2 réactions à l'histoire d'arbo
CVS mais je crois qu'on a déjà atteind la majorité pour
la simplicité.

Eric
-------- Message d'origine--------
De:     address@hidden de la part de Stephane Galles
Date:   mar. 01/03/2005 13:56
À:      TSP; tsp-devel
Cc:    
Objet:  Re: RE : [Tsp-devel] Java : TSP-CDF-Writer

>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.
> 
>
OK, c'étais bien ce que je pensais : Résoudre ce problème est un véritable
petit projet en tant que tel.

Je mets donc cette fonctionnalité de coté pour le jcdfwriter

>
> 
>
>>-----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
>>   
>>
>>------------------------------------------------------------------------
>>
>>---------------------------------------------------------
>>
>>CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.
>>
>>SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.
>>
>>
>>
>>This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.
>>
>>If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.
>>
>>---------------------------------------------------------
>>   
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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