Re: [Tsp-devel] Sondage : vos idées pour un 'consumer-server Web TSP'

[Eric NOULARD]

 Selon Stephane Galles <address@hidden>:

> >
> >
> >1) Je ne connais pas grand chose au Woueb, ni à la securité,
> >  
> >
> >et ce besoin est un peu loin de nos bancs.
> >
> OK, Je le ferai donc éventuellement comme simple exercice pour moi (si 
> j'ai le temps,
> mais j'y reviendrai plus loin  ;)  )
> 
> Neanmoins, Eric semblait quand même enthousiaste, et peu être pourrait - il
> expliciter les raisons qui lui font croire que :
> "Le schéma que tu [je] décris n'est pas débile du tout".
> Il est vrai que moi meme je n'ai aucune raison précise de croire
> que cela sert à quelque chose !!!

C'est utile car même en local aujourd'hui les gens que je connais font
de la gestion de conf "un peu" primaire de leur essais. L'interface aurait 
le mérite de rajouter cette "gestion d'essai" de premier niveau
pour "pas cher".

Evidemment une fois que les essais sont "de référence" les 
garants de conf essai les passent sous CVS/ClearCase etc...

Yves ne voit pas l'intérêt aujourd'hui parce qu'un banc est "dédié"
à une mission satellite et à une tâche particulière:
 "validation LV pour ROCSAT2"

Demain avec un banc numérique la reconf d'un banc peut prendre
moins de 30 minutes (hypothèse multi-mission microsat par exemple)
et se faire A DISTANCE. 
Je peux donc "voler" le banc d'une mission pour 3 jours car il est 
inutilisé. Si c'est le cas il est peu probable que j'aille m'installer
devant ce banc pour passer des essais et encore moins probable que
je le déménage pour qu'il soit à côté de moi.

En gros je penses que les bancs numériques (ou avec OBC multi-mission)
seront facilement utilisables "à distance" et donc ton système présente
un gros intérêt à moyen/long terme.

Evidemment ça dépasse TSP caril faut aussi une conduite de test "déporté"
mais ça on est en pas très loin sur microsat (filière CNES sur laquelle
je travaille actuellement)

> >3) Par contre plusieurs choses me chagrine
> > - Pourquoi le débit serait insuffisant, alors que tu peux tout ramener
> >après ? 
> > - Je trouve le stockage par une BD locale au server un peu dommage. Je
> >preferais un mode push/pull (applet)
> >
> Justement, le but est de ne jamais RIEN ramener coté navigateur afin
> de n'avoir AUCUN code spécifique pour utiliser l'application sur le client.
> Sinon on retombe sur consumer 'client lourd' que l'on a déjà : GDISP.
> Là je prends le contre pieds complet de GDISP.

Il faut pouvoir ramener des choses pour une mise en conf de "référence"
> 
> Pour résumer ce que je veux faire, c'est un Enregistreur/Browser de sample
> TSP dont le code applicatif tourne entiérement coté serveur.
> Via l'interface Web tu indiques la zone de courbe que
> tu souhaites voir afficher après l'enregistrement. Puis tu peux
> zoomer/dezoomer, etc...D'ou :
> - facilité de déploiment (aucun !),
> - pas besoin de bande passante particulière (un modem RTC est OK)
> - passage des firewall (eventuellement en HTTPS comme disait Eric)
> (et je sais deja ce que je vais utiliser pour les courbes : 
> http://cewolf.sourceforge.net/,
> regardez les screenshoot).

Ca à l'air sympathique.

> 
> Mais encore une fois c'est un but que je me suis fixé 'a prori', meme si 
> cela ne
> sert à rien 'a posteriori'  :). Par contre, comme je compte bien 
> designer l'appli
> aux petits oignons, la plus grosse partie du code JAVA du serveur 
> devrait pouvoir
> etre utilisée sans modification pour coder la même appli mais en tant que
> client lourd JAVA SWING (en gros il n'y aura que la couche de
> présentation à modifier si je ne m'y prend pas trop mal).

J'y comptais bien même si je ne l'avais pas dit.
La conduite de test microsat fonctionne plus ou mions sur ce principe
Un serveur lié au PE + une applet servie par apache, puis l'applet
ouvre une socket avec le serveur côté PE, de ce fait on peut
ouvrir +ieurs CdT sur différents poste. L'idée de Stéphane est similaire
mais plus "jolie/rusée" vu que moins de chose transitent entre le serveur
Web et le client.
> 
> Enfin, concernant la présence d'un dispositif de sérialisation des données
> coté serveur Web (une BD ou quelques chose de plus spécifique
> comme disait Eric), c'est l'architecture meme d'une appli Web qui l'impose,
> il faut serialiser des meta data au minimun, et pour cela
> il y'a rien de mieux qu'une BD (surtout avec des petits bijous comme 
> Hibernate
> http://www.hibernate.org/).

Je suis d'accord avec Stéphane même si je connais pas hibernate :))
Je connais Hibernatus mais ça doit pas être relié :))
> 
> >Sinon je dit GO pour ta TODO liste avec le datapool en RAW et tutti
> >quanti. Mais c'est vrai que le tout va te demander du temps. Tu en es ou
> >de tes recherches de boulot ? 
> >
> Justement...venons en à cela...
> hum... je commence à bosser lundi 5 décembre... pour, pouf, cela a été plus
> vite que je ne pensais (tant mieux hein ! la neige cela ne nourrit pas !).
> 
> Hors, indépendemment de ma lubie d'appli TSP web, je me rend compte
> du coup que ma TODO list datapool en RAW et tutti risque d'être 
> compliquée à tenir
> dans des temps raisonnables puisque je ne pourrai pas bosser dessus à fond.
> Coder par épisodes, c'est jouable, mais specifier/designer par episodes, 
> j'ai un peu peur
> des changements de contexte :
> - La problématique du 'comment ajouter simplement des types' n'est pas 
> triviale.
> - Il faut réfléchir au design de l'API entre le GLU et le provider pour 
> des types multiples
> (là, c'est pas trop trop dur, on est encore en RAW à ce moment, mais le 
> design du datapool
> RAW dépend de cette réponse)
> - Idem, Il faut réfléchir au design de l'API driver consumer, plus 
> compliqué.
> - Ce qui m'inquiete le plus : comment coté client bufferiser des données
> qui sont maintenant heterogènes, en taille/types.
> - Implémentation XDR de la couche de transport. Il va falloir benchmarquer
> parceque je me rappelle qu'à l'epoque l'encodage XDR d'un double était
> super pénalisant.
> - Il faut ajouter de nouvelles choses dans les specs car les structures RPC
> vont encore bouger (gestion du type)
> 
> Enfin, je n'arrive pas trés bien à voir comment faire de l'itératif sur ces
> problèmes.
> 
> En résumé dans quelle situation nous trouvons nous actuellement 1, 2, ou 3 ?
> 
> Situation 1) :  Il faut trés trés vite les type multiples et le vecteurs 
> et je ne suis pas l'homme
> de la situation car je n'aurai vraiment pas le temps de produire 
> quelques chose
> d'utilisable  rapidement à cause de mon nouveau travail
> Dans ce cas, il vaut peut etre mieux que quelqu'un de plus permanent
> s'y colle et dans je pourrai indirectement aider en donnant mes
> avis à 2$CAN sur ces problèmes s'ils sont évoqués dans la mailing list
> 
> Situation 2) : Il ne faut pas vite les types multiples et les vecteurs, 
> et je peux
> essayer de discuter avec vous des solutions que je pense pouvoir mettre 
> en oeuvre
> pour converger sur des idées d'implémentation. Ce sera obligatoirement 
> trés itératif
> et pas forcemment rapide, mais Linux ne s'est pas fait en un jour.
> Et puis de temps en temps de regarderai un peu mon fantasme consumer serveur
> Web TSP.
> 
> Situation 3) : Eric nous prouve qu'il est absolument indispensable 
> d'avoir un consumer serveur
> Web TSP, et cela devient ma tache prioritaire (bien sur, peu probable, 
> car je comprends bien qu'avant d'avoir
> des afficheurs de courbes en réalité vituelle 3D avec MP3, il vaut mieux 
> avoir un protocol complet...).
> Mais là, comme c'est assez facile à faire, je doit pouvoir produire un 
> proto relativement rapidement.

Mon avis personnel est que l'on est dans une situation entre 1 et 2 
j'aurais besoin de façon opérationnelle d'un TSP multi-types d'ici 
mi-février.
Il ne faut pas que ça t'empêche de commencer à concevoir quitte
à ce que ce soit (moi ou un autre Syntegriste) qui implémente.
(suivant le temps que tu auars pu y passer)
Ta touche de conception nous sera forcément utile.
Ensuite reste un choix important, choisis donc ce qui te motive
le plus :)))

Clairement le TSP consumer-serveur Web est très joli mais pas
urgent (en ce qui me concerne).

See you bientôt

Eric
> 
> Stephane.
> 
> 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
> 


-- 
---
Erk