je ne connais ni Jaxl, ni Movim, mais je connais bien PHP et XMPP. Je pense simplement que les mots furent mal choisis par l'auteur.
XMPP a une logique très asynchrone au contraire, dans ceci qu'on ne va pas envoyer une requête, puis attendre la réponse en bloquant le reste (et avant d'envoyer une autre requête). On va plutôt envoyer une série de requêtes en parallèles (si ça a du sens), et on recevra (ou non) les réponses quand elles arriveront: dans 1/100 de secondes (automatique), ou même dans un jour (réponse par un humain), voire jamais, etc. On suit les réponses par des systèmes d'identifiants, de thread, etc. Et si on veut envoyer une nouvelle requête (liée logiquement ou quelque chose qui n'a rien à voir), on n'est nullement bloqué; tout se fait en parallèle.
XMPP est donc typiquement asynchrone, contrairement à ce qui fut dit.
Maintenant dans cet article, j'imagine que ce que l'auteur entendait, c'est que XMPP est "connecté": on ouvre une socket TCP et on la laisse ouverte tout du long. Puis on y balance des requêtes si nécessaire ou on en reçoit d'autres entités.
PHP, tel que géré par un serveur web "habituellement", sera typiquement "non connecté". Un site web, ce sera en général des petites sessions extrêmement courtes (le temps que la page s'ouvre). Et on ne peut pas "sauver" ni partager une même connexion socket d'une session PHP à l'autre par exemple (pour autant que je sache. Peut-on le faire dans d'autres langages côté serveur par contre? Je ne sais pas). Ensuite il peut y avoir des contournements, par exemple avec des requêtes Ajax pour faire durer beaucoup plus longtemps une session PHP, ou bien Comet, plus récemment Websocket (mais c'est pas encore dans les navigateurs récents). Ces diverses méthodes restent tout de même limitées (le web n'est simplement pas fait pour ça par design).
Ou bien du côté XMPP, on a une extension pour transformer notre socket connectée en BOSH non connecté.
Sinon en dehors de cela, si, PHP — si exécuté hors web — pourrait tout à faire avoir des sessions infinies (comme n'importe quel langage) et n'a pas de problème pour XMPP.
En gros, j'imagine que l'auteur ne parlait pas de synchronicité, ni de PHP (mais du web). Il parlait du modèle de connexion longue de XMPP et de celui de session à vie extrêmement courte du web. Des logiques totalement contraire par design.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: asynchrone?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.3 est sorti ! Que ferez vous pour la 0.4 ?. Évalué à 10.
Salut,
je ne connais ni Jaxl, ni Movim, mais je connais bien PHP et XMPP. Je pense simplement que les mots furent mal choisis par l'auteur.
XMPP a une logique très asynchrone au contraire, dans ceci qu'on ne va pas envoyer une requête, puis attendre la réponse en bloquant le reste (et avant d'envoyer une autre requête). On va plutôt envoyer une série de requêtes en parallèles (si ça a du sens), et on recevra (ou non) les réponses quand elles arriveront: dans 1/100 de secondes (automatique), ou même dans un jour (réponse par un humain), voire jamais, etc. On suit les réponses par des systèmes d'identifiants, de thread, etc. Et si on veut envoyer une nouvelle requête (liée logiquement ou quelque chose qui n'a rien à voir), on n'est nullement bloqué; tout se fait en parallèle.
XMPP est donc typiquement asynchrone, contrairement à ce qui fut dit.
Maintenant dans cet article, j'imagine que ce que l'auteur entendait, c'est que XMPP est "connecté": on ouvre une socket TCP et on la laisse ouverte tout du long. Puis on y balance des requêtes si nécessaire ou on en reçoit d'autres entités.
PHP, tel que géré par un serveur web "habituellement", sera typiquement "non connecté". Un site web, ce sera en général des petites sessions extrêmement courtes (le temps que la page s'ouvre). Et on ne peut pas "sauver" ni partager une même connexion socket d'une session PHP à l'autre par exemple (pour autant que je sache. Peut-on le faire dans d'autres langages côté serveur par contre? Je ne sais pas). Ensuite il peut y avoir des contournements, par exemple avec des requêtes Ajax pour faire durer beaucoup plus longtemps une session PHP, ou bien Comet, plus récemment Websocket (mais c'est pas encore dans les navigateurs récents). Ces diverses méthodes restent tout de même limitées (le web n'est simplement pas fait pour ça par design).
Ou bien du côté XMPP, on a une extension pour transformer notre socket connectée en BOSH non connecté.
Sinon en dehors de cela, si, PHP — si exécuté hors web — pourrait tout à faire avoir des sessions infinies (comme n'importe quel langage) et n'a pas de problème pour XMPP.
En gros, j'imagine que l'auteur ne parlait pas de synchronicité, ni de PHP (mais du web). Il parlait du modèle de connexion longue de XMPP et de celui de session à vie extrêmement courte du web. Des logiques totalement contraire par design.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]