Je m'intéresse depuis quelques semaines à une technologie appelée COMET (ou encore HTTP Streaming). Son principe est simple : créer une connexion persistante entre le client et le serveur et s'en servir pour "pousser" les informations du serveur vers le client (sans que le client ne fasse une quelconque requête : voir schéma comparatif AJAX / COMET).
Cela permet naturellement d'augmenter encore un peu la réactivité de l'application. Exemple : l'intégration de Gtalk dans Gmail utilise cette technologie, Meebo aussi.
La technologie n'est pas nouvelle, mais ces utilisations montrent qu'elle maintenant probablement mûre pour une utilisation plus large. Si il y a de la demande sur le sujet de la part de mes chers lecteurs, je ferai un tutoriel sur le sujet, étant donné qu'il n'en existe pas à ma connaissance en français.
[EDIT] : le tuto est maintenant là.
vendredi, mai 5
COMET : successeur ou complément d'AJAX ?
Inscription à :
Publier les commentaires (Atom)
11 commentaires:
Ah oui, il y a de la demande ! Ca ne va pas m'empêcher d'aller à la pêche aux infos mais j'attends ce futur billet avec impatience
Pourquoi attendre de savoir si il y a de la demande pour faire un tuto ? ;)
Surtout que si il n'y a vraiment rien en français actuellement, c'est encore plus intéressant.
Bon, j'avoue... j'espérais secrètement ne pas avoir de demandes pour pouvoir ne rien faire !
Plus sérieusement, j'ai encore du mal à percevoir le profil de mes visiteurs : mes billets ont été assez peu techniques jusqu'à présent, et j'ai tendance à croire que la proportion de développeurs est faible parmi mes lecteurs.
Comme je dois faire des choix parmi les sujets web 2.0 auquels je touche, j'essaie de cibler au mieux mes billets (et le temps que j'y consacre).
Conclusion : je reste à l'écoute de vos demandes et de vos suggestions.
Un tuto serait TRES interessant!
Je met ce blog dans mes favoris!
un tuto + un début de communauté voila de quoi se mettre au travail.
bon courage
Je confirme je suis très intéressée également !
Et hop, "Le web 2.0, c'est pas du buzz "... en favoris
J'attends avec impatience ;-)
Ah oui, un tuto !! Moi qui fait de la veille technologique sur ce sujet, j'en serai très friande !! D'ailleurs, si vous avez quelques sources à me communiquer...
Donc, pour faire du Comet qui fonctionne plus de 30 secondes, il faut avoir la main sur son serveur web, et règler le time out sur une plus longue durée ?
Je trouve que cette méthode fait un peu "bricolo". Peut être bien encore un peu + que l'Ajax ;-)
Ca utilise le fameux "frame trick", donc c'est forcément un peu bricolo... mais qu'est ce qui ne l'est pas dans le développement web ?
Modifier le timeout d'un serveur dans le code n'est pas compliqué... mais c'est indispensable étant donné que le web n'a pas été pensé pour les connexions http à longue durée de vie qui sont le principe de COMET.
Le principal soucis avec Comet (HTTP streaming) c'est la persistance des connections.
Donc sur une application web qui doit streamer sur 100 clients il y a 100 connections ouvertes constament.
Dans la cas d'Apache, l'implémentation de ce genre de techno implique un tuning trés fin du serveur. Par exemple le fait de maintenir plus de 256 connections ouvertes en même temps implique une reconfiguration du serveur.
Du coup il y a pas mal de code qui doit être dédié à la detection d'activité du client ainsi qu'aux fermetures de sessions http.
En conclusion, Comet n'est ni un complément ni un successeur d'AJAX, pour reprendre un post plus haut, c'est du bricolage.
Qui plus est c'est du bricolage lourd. Déjà faire un framework AJAX robuste et compatible avec tout le monde n'est pas une mince affaire ... Pour la version Comet d'une appli, il faut bien sur un framework robuste qui gére les erreurs, les timeouts, les notifications à l'utilisateur (ex.:chargement en cours...). Mais il faut aussi y rajouter le contrôle des connections ouvertes,la detection de l'activité du client, la configuration du serveur au niveau performances et aussi aux niveaux dépassement de capacités.
Dans le cas du dépasssement de capacité le client à beaucoup de mal à connaitre l'état du serveur puisque ce dernier le mettra en file d'attente.
En gros : Comet comme Ajax demandent beaucoup plus de connaissances et de travail que le web standard. Et dans le cas de Comet l'approche peut être dangereuse si on part dans la production d'une appli pour s'apercevoir plus tard que le serveur ne suis pas ou qu'il y a des limitations techniques fortes.
Pour info je suis programmeur freelance PHP/Mysql/Javascript, connais assez peu Java/TomCat dans ces plus profonds recoins mais peut être que Java propose des choses interressantes.
Voila pour ma propre experience.
http://www.bzctoons.net
Tout à fait d'accord avec ces remarques (qui sont d'ailleurs précisées dans sur la page d'ajaxpatterns que j'ai mise en lien).
La majorité des projets ne sont pas prêts pour une mise en production à grande échelle de COMET... mais certains y arrivent ! Gchat, ce n'est pas rien quand même !
COMET, avec ses connexions HTTP persistantes, va à l'encontre de certains paradigmes du web... mais c'est suffisamment intéressant pour que pas mal de monde s'y lance.
Exemples :
- Apache étudie de nouvelles façons de s'adapter aux connexions de type COMET.
- Dojo toolkit fournit un début de framework pour connexion COMET (pas testé personnellement).
- La technique est employée dans de nombreuses applications en ligne récentes (genre Meebo)
Alors, successeur ou complément ? Complément pour un certain nombre de sites, c'est sûr à l'heure actuelle. Successeur éventuellement, si les serveurs web font des efforts pour s'adapter à ce type de connexion, si les navigateurs du futur nous facilitent la tâche et si de vrais frameworks bien solides apparaissent.
Enregistrer un commentaire