Des echos de CanadaOnRails

Community FR
1

Salut,

La conférence CanadaOnRails à Vancouver a commencé
aujourd’hui.

D’après la présentation qu’actuellement DHH est en train de faire,
dans Rails dans le futur, tout ce qui est pagination va être
retiré du framework est dispo sous forme de plugin. Il y a ptêtre
d’autres trucs qui vont partir, je sais pas encore.

DHH a sûrement fait d’autres révélations mais je sais pas
encore.

Il y a une photo un peu étonnante mais on a pas le contexte
qui va avec :

-- Jean-François.
2

Ma pomme:

DHH a sûrement fait d’autres révélations mais je sais pas
encore.

D’après le peu que j’ai pu comprendre, il a parlé de
simply_restful, actuellement sous la forme d’un plugin qui
sera intégré dnas le futur dans Rails.

Il a évoqué Twisted, un framework pour faire de la
programmtion asynchrone sous Python, mais je sais
pas pourquoi il a parlé de ça . Il veut faire marcher
Rails sur twisted? ou s’en inspirer ?

Il y a un truc qui s’appelle Armageddon mais je sais pas
ce que c’est. Il a parlé de “flash connection”, un système
de sockets ouvertes ?

simply_RESTful
http://svn.jamisbuck.org/rails-plugins/simply_restful/

Bon c’est encore trop frais tout ça.

РJean-Fran̤ois.

3

il y un salon campfire pour ceux que ca intersse : https://
37s.campfirenow.com/room/7247

et quelques infos par la RubyNow: Ruby Jobs | Niche Ruby on Rails Jobs Board

Voila HTH

4

ma poire :

Bon c’est encore trop frais tout ça.

Rails 1.2 est prévu dans 2 / 3 mois. 2.0 avant la fin de
l’année.

DHH veut retirer les components, AWS, les “rich habtms”
. Les paginations seront dispo sous la forme de plugin .

En fait l’histoire de l’armageddon
, c’est en gros du code RJS pour ouvrir une socket côté
client. Pour que le serveur puisse envoyer des données
au lcient) travers cette socket. Sans que le client
ne fasse des reqûêtes tous les x minutes pour voir
s’il y a du nouveau. Dispo d’abord sous la forme de plug-in.

-- Jean-François.
5

Le jeudi 13 avril 2006 à 19:52 +0200, Jean-François a écrit :

simply_RESTful
http://svn.jamisbuck.org/rails-plugins/simply_restful/

Ca c’est excellent, j’avais été obligé de faire un controlleur perso qui
redéfinit des trucs pour implémenter quelque chose d’équivalent. Faire
en sorte que ce soit le framework qui propose une interface REST est une
bonne idée.

6

Bonsoir tout le monde.

C’est assez inquiétant toutes ces nouvelles.

DHH veut retirer les components

Mais, n’était-ce pas là un bon moyen de distribuer aux autres son code
Rails,
sans avoir à venir “polluer” le répertoire application/ ?

Rails 1.2 est prévu dans 2 / 3 mois. 2.0 avant la fin de
l’année.

Ca m’apprendra à acheter le bouquin. J’espère que les modifications ne
feront pas de Rails 2.0 un autre produit que ce qu’est Rails 1.x

En fait l’histoire de l’armageddon
, c’est en gros du code RJS pour ouvrir une socket côté
client. Pour que le serveur puisse envoyer des données
au lcient) travers cette socket. Sans que le client
ne fasse des reqûêtes tous les x minutes pour voir
s’il y a du nouveau. Dispo d’abord sous la forme de plug-in.

Si je comprends bien, ce n’est plus le client qui va utiliser AJAX
pour rafraîchir
une partie de la page (au sens code), mais le serveur qui va envoyer au
client
de nouvelles données. Sur le papier, c’est génial (qui a dit le Web, 3.0
?).
Mais pour que cela fonctionne, notamment dans un environnement avec
des routeurs, il faut que ce soit le client qui initie la connexion
vers le serveur, et que celui-ci ne la ferme pas, pour envoyer, quand
c’est nécessaire, les fameuses données.
Quid des attaques par déni de service ?

–
Guillaume “Zifro” DESRAT
http://…/
– Aah Jeez…I Wish You Could See This…Lights Coming Up…I’ve
Never Seen A Painting That Captures The Beauty Of The Ocean…I’m
Gonna Make You Rich, Bud Fox…Rich Enough You Can Afford A Girl Like
Darien…This Is Your Wake-Up Call, Pall…Go To Work…DROP IT!!!
(3 Steps Ahead - Drop It)

7

2006/4/14, Guillaume Zifro DESRAT [email protected]:

pour rafraîchir
une partie de la page (au sens code), mais le serveur qui va envoyer au
client
de nouvelles données. Sur le papier, c’est génial (qui a dit le Web, 3.0?).
Mais pour que cela fonctionne, notamment dans un environnement avec
des routeurs, il faut que ce soit le client qui initie la connexion
vers le serveur, et que celui-ci ne la ferme pas, pour envoyer, quand
c’est nécessaire, les fameuses données.
Quid des attaques par déni de service ?

Le problème c’est que c’est justement à l’encontre complete des
fondements
du protocle HTTP. Si c’est le serveur qui gère l’envoie de donné, on
reviens
à du client serveur, pourquoi faire de la page web alors ? pour les
standards ? bah utilisons xul pour les uns, et xaml pour les autres …

Personnellement (même si ça n’a pas grand chose à voir avec rails)
j’aime
pas du tout ces orientations, comme si la boucle étais bouclé et que
bientot
on allais revenir à 20 ans (voir plus…) en arrière. On vas finir avec
un
Terminal couleur qui verras tourner un navigateur directement en
mémoire, et
on verras tout sur le “web 2.0, 2.3, 3.0 …” …

Je n’irais pas bloquer une fac ou me mettre en travers de la voie pour
autant, mais c’est dommage.

8

En fait l’histoire de l’armageddon
, c’est en gros du code RJS pour ouvrir une socket côté
client. Pour que le serveur puisse envoyer des données

Le problème c’est que (heureusement) les sécus des navigateurs
interdisent ce genre de choses (d’ailleurs je doute même qu’il y ait une
interface pour ça).
Il va falloir employer des plugins pour ça. Qui dit plugin dit diffusion
limitée et si ce n’est pas supporté par un des deux gros poids lourds du
milieu, ça risque de faire long feu.
Même si c’était réaliste, ça poserait plein de problèmes de sécurité.
Faire un serveur qui va écouter des requêtes externes et exécuter du
code js : avec quelle zone de sécurité ? quid des problèmes de
cross-domain actuellement interdits ? AMHA ce n’est pas pour demain.
Quid aussi des firewall, des réseaux natés (de plus en plus fréquents
même sur des connexions persos)

Le vendredi 05 mai 2006 à 20:21 +0200, Alain a écrit :

Le principe de l’envoie de données par le serveur vers les clients est
une ‘nouveau’ concept AJAX qui porte le nom de “Commet”.

On parlait aussi de PUSH sur ActiveDesktop quand c’est MS qui avait
inventé ça (on remonte à 98 là ). Il y a eu d’autres appellations mais
rien de nouveau, et pour cause : les problèmes posés n’ont à priori pas
beaucoup de solutions satisfaisantes.

L’idée est de sauver de la bande passante pour le serveur en faisant les
updates uniquement lorsqu’ils sont nécessaires.

Euh, je ne suis même pas sûr que ça économise grand chose.
Il y a deux modèles :

  • le client annonce quand il ouvre son serveur et annonce quand il se
    déconnecte : tu risques d’avoir beaucoup de messages d’annonce pour peu
    de contenu.
  • le client ne s’annonce pas en déconnexion, et dans ces cas là tu vas
    jouer au timeout et faire du push vers plein de clients qui ne sont plus
    connectés : les échecs de connexion peuvent couter cher si les gens ont
    des firewall parano, ça entraine aussi plein de support pour les gens
    qui vont raler parce que leur firewall a déclaré une “attaque” …
  • le client ne s’annonce pas et là je ne vois même pas comment le
    contacter

D’ou est ce que tu tiens l’information de ROR 2.0 pour la fin de
l’année? Ã?a ressemble plus à une rumeur mal informée qu’à un fait. Un
changement de version sur le premier chiffre correspond à un changement
MAJEUR technologique (normalement) et pour l’instant je n’en vois pas…

Je suis aussi étonné, en regardant régulièrement le svn, je ne vois rien
qui me fait penser qu’un tel changement se prépare.

9

Le principe de l’envoie de données par le serveur vers les clients est
une ‘nouveau’ concept AJAX qui porte le nom de “Commet”.

L’idée est de sauver de la bande passante pour le serveur en faisant les
updates uniquement lorsqu’ils sont nécessaires.

Le AJAX client vers serveur va rester, il va juste y avoir une nouvelle
façon pour pousser du contenu vers les clients, c’est tout.

D’ou est ce que tu tiens l’information de ROR 2.0 pour la fin de
l’année? Ã?a ressemble plus à une rumeur mal informée qu’à un fait. Un
changement de version sur le premier chiffre correspond à un changement
MAJEUR technologique (normalement) et pour l’instant je n’en vois pas…

10

Ã?ric Daspet wrote :

| Il va falloir employer des plugins pour ça. Qui dit plugin dit diffusion
| limitée et si ce n’est pas supporté par un des deux gros poids lourds du
| milieu, ça risque de faire long feu.

DHH en a un peu parle sur la ML rails-core: le code établissant la
socket est un (petit) bout de Flash.
AFAIR as I remember il a evoque Comet en disant que le problême qu’il
voyait avec Comet était qu’il fallait changer en profondeur
l’architecture de ton application.

| > L’idée est de sauver de la bande passante pour le serveur en faisant les
| > updates uniquement lorsqu’ils sont nécessaires.
|
| Euh, je ne suis même pas sûr que ça économise grand chose.
| Il y a deux modèles :
| - le client annonce quand il ouvre son serveur et annonce quand il se
| déconnecte : tu risques d’avoir beaucoup de messages d’annonce pour peu
| de contenu.
| - le client ne s’annonce pas en déconnexion, et dans ces cas là tu vas
| jouer au timeout et faire du push vers plein de clients qui ne sont plus
| connectés : les échecs de connexion peuvent couter cher si les gens ont
| des firewall parano, ça entraine aussi plein de support pour les gens
| qui vont raler parce que leur firewall a déclaré une “attaque” …
| - le client ne s’annonce pas et là je ne vois même pas comment le
| contacter
|

Le flow tel que présenté par DHH est:

Client A --ouvre un esocket vers le Serveur de Sockets
Client B --fait un appel xhr que le client A devrait voir → FCGI
–envoie
un message au → Serveur de Socket

Le serveur de socket marche comme un software bus particulièrement
simple: il permet juste d’envoyer du texte à une socket identifiée par
un ID.

Pour ce qui est des “économies”, si on considère l’exemple type
d’application qui bénéficierait d’Armageddon, une liste ToDo partagée,
on économise quand même. Dans le cas sans Armageddon:

Le client se connecte au serveur HTTP une première fois pour avoir la
liste puis par exemple toute les secondes pour avoir le dernier état
de la liste. Donc toutes les secondes on a l’établissement d’une
connection, la demande au serveur et à la BDD de la nouvelle liste.

Avec Armageddon:

Le client se connecte au serveur HTTP et au serveur de socket, puis
attend que le serveur de socket lui envoie les updates: pas de
connection en plus, plus de demande superflue au serveur sur une
hypothetique nouvelle liste, plus d’accès en plus à la BDD.

Donc si, je pense que l’on peut y gagner. De plus si on considère
le cas d’utilisation d’Armageddon canonique (plusieurs clients accèdent
à une resource partagée et doivent avoir au plus tôt son nouvel état
s’il y a eu des modifs par un autre client) ça simplifie aussi un peu le
design de l’application en question.

| Je suis aussi étonné, en regardant régulièrement le svn, je ne vois rien
| qui me fait penser qu’un tel changement se prépare.

AFAIR, DHH a évoqué une 1.2 pour avant la fin de l’année et une 2.0 pour
dans un futur incertain
(ongoing by Tim Bray · Canada on Rails)

–
Frederick R. aka Sleeper – [email protected]

Write clearly - don’t be too clever.
- The Elements of Programming Style (Kernighan & Plaugher)