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

[Stephane Galles]

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

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

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

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

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

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

Stephane.