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

[Ibou de Joie]

Alors la respect Monsieur le canadien, je vois que dans votre pays on a
pas froid aux yeux !!! (Elle etait facile, mais cela me fait plaisir de
taquiner le skonse)

Pour ma part
1) Je ne connais pas grand chose au Woueb, ni à la securité (j'ai passé
nessus sur ma machine, une vrai passoire), et ce besoin est un peu loin
de nos bancs.
2) Mais je trouve l'idée geniale et super élégante, de faire un
consummer/server woueb, surtout avec de la sécurisation et des trucs
sous Windows (plus à pleurer le RPC....)
3) Par contre plusieurs choses me chagrine
 - Pourquoi le débit serait insuffisant, alors que tu peux tout ramener
après ? ce genre de client externe devrait se contenter de quelques
variables à quelques Hz.
 - Je trouve le stockage par une BD locale au server un peu dommage. Je
preferais un mode push/pull avec une "applet" ou autre chose sur le
client qui trace les courbes.
 - La prog d'un res à distance m'apparait pas trop nécessaire.

=> en gros je trouve cela super, si cela me permet de programmer à
distance un genre de synoptique "Super Lent" de quelques variables (voir
meme pas des courbes, mais juste en alphanumérique). Mais comme je ne
suis pas sur d'avoir bien tout compris, et que en plus tu voulais te
faire du pédagogique, fais-toi plaisir.

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 ? Cela doit etre le calme plat vu ta
présence sur la mailing-liste :=}

Y++


On Wed, 2003-12-31 at 01:34, NOULARD Eric wrote:
> Salut le Caribou(t en train),
> 
> Ben oui tu étais seul le Week-End dernier,
> mais je sens que ma réponse va être mise en attente
> jusque l'année prochaine donc...
> 
> Quoiqu'il en soit avant un départ non mérité pour passer
> le 31-->1 à Chartres je donne mon avis à 2 euros avant
> d'aller me coucher.
> 
> D'abord j'applaudis des 2 mains vus que dans ce que tu décris
> un certain volume de boulot.
> 
> Côté pratique je rappelle qu'actuellement il n'y a dans
> 'jstp' que le côté consumer mais pour ton affaire ça
> devrait suffir.
> 
> Le schéma que tu décris n'est pas débile du tout.
> En revanche concernant l'utilisation de MySQL pour stocker le flux
> effectivement reçu j'emmettrais certains doutes.
> Personnellement je serais plutôt tenté de stocker un "vrai"
> fichier dans un WebFolder (Microsoft) 
> de l'utilisateur via les possibilités
> WebDAV d'Apache.
> 
> L'utilisation de MySQL peut toutefois être très intéressantes
> pour gérer les méta-données de l'enregistrement 
> (date,heure,utilisateurs,droits de regards/consultation, provider
>  utilisé,...) 
> 
> Le débat 'enregistreur rapide' côté serveur ou côté client est
> uniquement un problème de débit max entre le consumer et le provider
> donc ton idée n'est pas redondante.
> 
> Toutefois tu supposes si je comprends bien que la machine hébergeant ton
> consumer-serveur-WEB voit sans problème (de firewall) les providers TSP.
> 
> En ce qui concerne le débat d'un TSP firewall-friendly, le canal de 
> commande SOAP seul n'est effectivement pas suffisant et ta solution me
> semble très élégante même si elle contourne un peu le problème.
> Ca ne veut pas dire qu'on ne pourrait pas passer le canal de données
> sur SSL. Dans tous les cas les 2 solutions ont leur intérêt et donc
> ta proposition n'est pas redondante avec un consumer distribué qui
> passe les firewall, surtout si tu ajoutes à ton serveur Web une BD
> qui te permet de faire de la gestion des données d'essais.
> 
> D'ailleurs dans le même ordre d'idées si tu pouvais t'arranger
> pour que l'on puisse utiliser ta conf apache et ton joli tsp consumer-
> serveur-Web avec HTTPS (au lieu de HTTP) ça pourrait être carrement
> plus 'vendeur' pour offrir des accès de types 'extranet' à ce serveur.
> 
> Donc en ce qui me concerne vas-y fonce, prends une bonne réserve
> de Caribou séché et code nous ça, ça sera génial.
> 
> Bon j'arrête là,
> Sauf pour une anecdote qui est que bien que n'ayant pas chassé le
> Caribou ce week-end j'ai quand même fais des raquettes 
> (certes à Font-Romeu et pas dans le grand nord Canadien) na !))
> 
> Sinon bonne et heureuse année à tous.
> 
> Eric
> 
> 
> Le dim 28/12/2003 à 13:25, Stephane Galles a écrit :
> > Ayant eu le temps de repenser à cette histoire de  'consumer-server Web 
> > TSP'
> > (j'ai un peu l'impression de parler tout seul ce weekend...),
> > je vous propose un peu de science fiction pour se fixer les idées sur ce 
> > que j'avais en tête,
> > 
> > le tout étant de savoir si cela sert à quelque chose en pratique...  (sic)
> > 
> > - Ce matin Monsieur Yves D. (j'ai masqué les noms pour protéger les 
> > innocents), n'est pas
> > sur son site de travail favori mais il aimerai bien savoir comment se 
> > passe son test qui est
> > en train de tourner dans un autre batiment.
> > - Il demander à un collègue de lui prêter un PC et se connecte via 
> > l'intranet au 'consumer-server Web TSP'
> > (cette machine est sur un autre sous-réseau protégées par un FireWall, 
> > mais celui-ci laisse passer
> > les connexions Web, si parceque...parque j'en ai décidé ainsi !)
> > - Monsieur D. entre son nom d'utilisateur et mot de passe sur le site du 
> > 'consumer-server Web TSP'
> > (pour deux raisons : 1 parceque c'est pas la peine que toute 
> > l'entreprise joue avec le serveur, et
> > 2 pour une autre raison que j'aborderai plus loin).
> > - Monsieur D. obtient alors la liste des provider TSP sur la machine à 
> > laquelle le
> > 'consumer-server Web TSP'  a ete lié lors de sa configuration (comme il 
> > se doit, il a été choisi
> > de ne pas mettre le serveur Web sur la machine du consumer pour ne pas 
> > dégrader les
> > performances du test)
> > - Monsieur D. choisit le provider, la liste des variables qu'il veut 
> > sampler, phase et période
> > et durée d'enregistrement. Il lance le test. Il arrive sur une page Web 
> > qui lui dit de patienter
> > jusqu'à la fin de l'enregistrement.
> > - Les donnés sont enregistrées dans une base de données, ajoutées aux 
> > autres enregistrements qu'il a avait réalisé
> > ces dernieres semaines. Ces enregistrements ne sont pas mélangés à ceux 
> > des autres utilisateurs du serveur,
> > puisque monsieur D. avait entré son nom d'utilisateur et mot de passe.
> > - L'enregistrement étant terminé, monsieur D. clique sur le lien de la 
> > page de consultation des
> > enregistrements. Il retrouve ses anciens enregistrements, ainsi que 
> > celui qu'il vient de créer.
> > Il consulte ce dernier, les courbes des différentes variables 
> > s'affichent. Par la même occasion
> > cela lui permet de montrer l'enregistrement à monsieur Eric N. qui était 
> > dans ce batiment
> > mais qui n'avais vraiment pas le temps de passer jusqu'au PC de monsieur 
> > D. qui était
> > le seul à avoir un Consumer TSP GTK. Et puis de toute façon le PC est 
> > sous Windows,
> > donc pour l'instant il n'était pas question d'installer un consumer 
> > (oui, je vous voie
> > venir avec le consumer en JAVA...mais bon...lisez la phrase suivante :). 
> > Et puis en plus le réseau sur lequel
> > se trouve le PC n'a pas un débit suffisant, d'ou l'intéret dans ce cas 
> > de ne pas faire
> > transiter les données de test.
> > - Monsieur D. décide que ce test est vraiment trés interessant. De 
> > retour sur son propre
> > PC, il se connecte de nouveau au Serveur Web TSP, et décide d'exporter 
> > cet enregistrement vers un fichier RES.
> > Il se log au serveur Web TSP, retrouve l'enregistrement qui est toujours 
> > resté stocké dans la base, puis
> > Il clique sur le lien 'Export d'enregistrement au format RES' et entre 
> > un nom de fichier local à son PC.
> > Le serveur effectue la conversion BD --> RES et le téléchargement FTP 
> > automatique place le fichier RES
> > résultant sur son PC.
> > 
> > Bon heu... voila... sachant que encore une fois :
> > - Je tourne en boucle dans mon coin alors que vous aller peut etre me dire
> > que c'est redondant avec la faculté à un consumer d'être distribué, et 
> > que cela
> > n'a donc aucun intéret.
> > - Ce système est peu etre redondant avec la notion de Recorder TSP local 
> > au provider
> > - Je ne sais pas vraiment si cela tiendrai les perfos pour faire des 
> > enregistrements
> > violents  (néanmoins une base MySQL est trés rapide et avait été pensée 
> > au départ pour
> > pouvoir mettre beaucoup d'entrée dans les tables et rapidement).
> > 
> > Voila, quelqu'un voit - il dans cette petite histoire des cas 
> > d'utilisation intéressants ?
> > 
> > Bien, sinon, je vais arreter de parler tout seul pour le Weekend.
> > 
> > Re - joyeuses Fetes.
> > 
> > Stephane 'Trappeur' G.
> > 
> > 
> > 
> > Stephane Galles wrote:
> > 
> > > Bonjour,
> > >
> > > Je cherche actuellement un sujet de développement pour améliorer mes 
> > > compétences
> > > en techno Web (pour l'anecdote Apache, Tomcat, JSP, Servlet, Struts,
> > > Hibernate, MySQL, XDoclets, WebServices)
> > >
> > > Hors, en y réfléchissant bien, il pourrait y avoir un intéret à accéder
> > > à un serveur TSP en distant via du HTTP.  Sans avoir besoin de configurer
> > > quoi que ce soit sur une machine, ni sur son réseau.
> > >
> > > Hors, TSP n'est absolument pas 'firewall friendly'. Et soyons clairs, il
> > > ne pourra jamais l'être (même si le canal de commande est implémenté en
> > > SOAP, il y aura toujours le problème du canal de données).
> > >
> > > D'où l'idée d'avoir un 'client léger' pour monitorer des données. Quand
> > > je dis client léger, c'est vraiment léger, pur HTTP. Pas d'applets, 
> > > car on retomberait dans
> > > la cas du 'firewall-pas-friendly'.
> > >
> > > Autrement dit, il faut un  'consumer-server Web TSP' .
> > >
> > > Bien sur, dans ce cas il ne pourra pas y avoir de courbe qui 'bougent' 
> > > en temps réel.
> > >
> > > Par contre on peut imaginer un refresh de courbes à la demande (refresh
> > > du navigateur), la possibilité de choisir ses symboles, etc...
> > >
> > > Je me dis également qu'une base de données type MySQL peut etre utile 
> > > également, mais
> > > là je ne vois pas encore trés bien pour quoi faire (j'ai peur 
> > > d'empiéter sur la notion
> > > de recorder disk TSP dont on ne sait pas encore s'il a sa place dans 
> > > un client ou bien
> > > dans le serveur, et de toute façon j'ai l'impression de mélanger les 
> > > responsabilités
> > > logicielles là).
> > >
> > > L'idée etant évidemment d'implémenter tout cela grace au code JAVA 
> > > d'Eric.
> > > On touille le tout, et on obtient un gros fichier .WAR (pour les 
> > > connaisseurs)
> > > full JAVA, extrement facile à installer dans TomCat sur toute 
> > > plateforme où
> > > tourne Tomcat (là où il y a une JDK en somme). Si on veut plus 
> > > robuste, on peut
> > > evidemment faire Apache + Tomcat.
> > >
> > > Donc que vous inspire tout cela ? Entourer le réponse :
> > > a) - "C'est génial et j'ai des idées d'applications !"
> > > b) - "Bof, bof..."
> > > c) - "Mouais..."
> > > d) - "Hum..."
> > > e) - "C'est nawak"
> > > f) - "T'es vraiment un blatte avec des grosses pattes, et tu nous 
> > > ennuis avec tes idioties."
> > >
> > > J'attend vos réactions/idée/insultes.
> > >
> > > Stephane 'Trappeur' G.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Tsp-devel mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > >
> > >
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> -- 
> Eric NOULARD
> E-mail: address@hidden
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
>