 |
| VID Web | |
| nve | 6-Jan-2011/0:11:32+1:00 |
| Dans quelle mesure pourrait-on réaliser ceci en REBOL ? http://www.atozed.com/intraweb/index.en.aspx En Delphi, on utilise ces composants normallement pour son apppli. Ensuite, on peut exécuter son appli normallement comme une appli Windows ou on passe en mode Web sans changer une ligne de code... Ce serait pas mal comme système non ? J'ai View de dispo sur mon OS je peux lancer mon appli en "client lourd", j'ai pas View pour mon système, je passe en mode Web. Avec cette méthode il faut avoir à minima un Rebol / Core. Après certains me diront, ce n'était l'objectif du plug-in brower... -Nicolas | |
| DocKimbel | 6-Jan-2011/13:21:13+1:00 |
| C'est une question intéressante, j'y ai un petit peu réfléchi il y a quelques années avec d'autres sur AltME (je ne retrouve pas trace dans les groupes publiques, je crois que c'était des conversations privées principalement avec Gabriele et Janko). Concernant la faisabilité, il y a deux parties à considérer : la partie purement graphique et la partie "logique de contrôle" (c'est à dire le code nécessaire pour rendre la partie graphique intéractive). Pour la partie graphique, pas d'obstacle particulier, il "suffit" d'écrire un compilateur VID -> HTML/CSS, ce qui en REBOL est relativement simple (mais peu nécessiter pas mal de code coté HTML/CSS pour simuler des composants complexes non disponibles nativement en HTML). Pour la partie logique de contrôle, ça devient beaucoup plus délicat. En effet, il est nécessaire d'avoir du code déclenché par les différents évènements (souris/clavier/système) pour, soit répondre aux actions utilisateurs (action suite à un clic bouton) soit, pour contrôler le "look & feel" du composant (hover sur un menu par exemple). Or, là où le bât blesse, c'est qu'il serait nécessaire de traduire le code REBOL extrait du VID (voire toute l'application) en code JavaScript correspondant, c.a.d., écrire un compilateur REBOL -> JS, ce qui n'est pas possible dans le cas général (REBOL est non-compilable par nature) et dans le cas particulier d'un sous-ensemble de REBOL compilable (en limitant les fonctionnalités du language), celà reste un travail lourd et complexe (mais possible). Un premier contournement possible de cet obstacle serait de n'utiliser que du code JS dans les blocs d'action de VID, mais celà serait très frustrant de ne pas pouvoir coder en REBOL et il resterait de toute manière à interfacer ce code JS avec le reste de l'application côté serveur écrite en REBOL. Une seconde option possible serait de laisser la partie logique de contrôle de l'UI complètement côté serveur, c.a.d. que tous les évènements clients seraient envoyés au serveur pour traitement et renvoi d'une réponse appropriée. Mais cette approche atteint également rapidement ses limites, car certains évènements (comme mouse-over, mouse-move,...) nécessitent une réaction très rapide pour garder une UI réactive et agréable à utiliser. Or, les temps de latence pour un aller-retour de paquets sur le net ne permettent pas de garder une réactivité suffisante pour ce genre d'usage. Par exemple, un aller-retour de mon PC, via Free, vers un de mes serveurs OVH =~30ms, si on ajoute 30ms pour le traitement coté serveur en moyenne, ça nous donne 60ms/req, soit ~16 évènements/sec. J'ai pris ici un cas favorable où le serveur est sur le même backbone que l'utilisateur, ce qui n'est pas le cas en général. Je dirais que 80 ou 100ms de latence entre client/serveur serait plus dans la moyenne, ce qui ne laisserait plus que ~10 évènements/sec possible pour le client, ce qui, a priori, risque d'être trop juste pour une UI réactive (imagine un menu dont les options changent de couleur de fond lorsque la souris passe par dessus, 100ms de latence pour chaque changement de couleur serait ressenti comme très lent pour l'utilisateur). Une utilisation limitée à du LAN pourrait régler en grande partie ce problème de lenteur, mais celà reste à tester pour valider l'hypothèse et il reste de toute façon la problématique de scalabilité du serveur pour encaisser des dizaines de requêtes par seconde et par utilisateur, tout en répondant très rapidement à chaque requête. Je pense que celà vaudrait le coup d'être prototypé (si quelqu'un a du temps libre pour çà). Cheyenne + un canal websocket pourraient être une bonne base pour un proto, dommage que les websockets aient été récemment désactivées dans les navigateurs pour cause de trou de sécurité dans le protocole de communication (devrait être corrigé d'ici quelques mois normalement). Pour revenir à ton exemple en Delphi, le language Delphi étant "bas niveau" comparé à REBOL ou même JS, il est facilement compilable en JS avec une séparation entre le code à migrer vers le client et le code à garder côté serveur pour interagir avec une BDD par exemple (quoique, je vois un "ServerController.pas" dans le projet, donc, il est probable que la séparation client/serveur du code soit faite explicitement par le développeur plutôt que par le compilateur). | |
| shadwolf | 6-Jan-2011/14:44:17+1:00 |
| En fait a partir du moment ou ton client a accès au net tu peut télécharger rebol/view. Sinon conceptuellement et si au lieu que le serveur http soit distant il soit local ( genre Cheyene! ) Aprè oui il faut prévoir interprete qui va produire les page HTML et le cheyenne et t'ouvrir le navigateur par defaut avec la page correpondant à la premiere fenètre. Il faut aussi se dire que la succession des fenetre dans une application vid est difficilement adaptable au web... C'est pour ca que le rebol plugin était une idée géniale. | |
| DocKimbel | 6-Jan-2011/15:33:23+1:00 |
| Shadwolf, la demande initiale de Nicolas est: "J'ai View de dispo sur mon OS je peux lancer mon appli en "client lourd", j'ai pas View pour mon système, je passe en mode Web." Plugin REBOL == REBOL/View == client lourd <> mode web. Idem pour installer un serveur web local, c'est de l'ordre du client lourd (téléchargement d'une application native). Pour ce qui est de simuler des successions de fenêtres en mode web (HTML/CSS/JS), ça ne pose aucune problème, tu peux modifier en JS, l'intégralité du DOM de la page à volonté sans avoir besoin de la recharger. | |
| coccinelle | 6-Jan-2011/16:13:47+1:00 |
| J'avais aussi fait un essai mais je ne retrouve pas le script. Plutôt que de partir du VID, j'avais fait le choix de partir des objets "face" directement. De mémoire, je me souviens que la génération de la partie graphique avait été assez simple car on retrouve plus ou moins les mêmes attributs des deux côtés. Par contre, comme le soulignait DocKimbel, la partie logique des contrôles était autrement plus difficile. Si la mise en oeuvre de l'appel du serveur n'était pas trop compliquée, toute la logique devant s'exécuter dans le browser était pour moi trop difficile à faire (génération du javascript ou interpréteur en JS du Rebol ou autre. L'arrivée du Plugin m'avait fait abandonner cela car il offrait une solution toute simple pour intégrer View dans une page HTML. | |
| nve | 6-Jan-2011/22:31:25+1:00 |
| Merci pour votre retour sur le sujet. J'ai lu en diagonale pour l'instant... En fait, voici comment je verrai les choses : On aurait un dialecte qui permettrait d'ecrire une application graphique / application HTML. Evidemment, il y aurait une restriction dans le choix de composants car il faudrait toujours avoir à l'esprit de pouvoir basculer de l'un à l'autre. De palier à l'absence de la partie graphique sur un système et des basculer sur le mode Web... D'offrir la possibilité à un client d'offrir soit une application client lourd classique comme au bon vieux ou un mode Web parce ce que finalement on veut que toutes nos applications soient dans un browser Web. Evidemment, le plugin était quelque part là pour cela. Sauf qu'encore une fois il faut faire le plugin pour les x navigateurs sur les x OS supportés. | |
| deglingo | 6-Jan-2011/23:17:32+1:00 |
| La conversion Rebol -> HTML/Javascript ressemblerait un peu à ce que fait GWT, le Google Web Toolkit (http://fr.wikipedia.org/wiki/Gwt - http://code.google.com/intl/fr/webtoolkit/ ) entre JAVA et HTML/Javascript, non ? Ca serait un RWT, un Rebol Web Toolkit ! | |
| DocKimbel | 6-Jan-2011/23:45:25+1:00 |
| Oui, tout à fait. Compiler du JAVA vers un langage de plus haut niveau comme JS est relativement simple, mais faire de même avec le langage REBOL est très difficile. Il y néanmoins des tentatives dont celle de Janko (https://github.com/jankom/RebToStatic). | |
|
Login required to Post. | |