Ã?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)