1

Un peu déçu par les limites de mon site de chat favori, j'ai envie de concevoir le mien où je pourrais facilement ajouter des fonctionnalités au fil des demandes des utilisateurs. Je pense notamment à des profils différents pour un même compte ou des générateurs de dés, ce chat ayant plusieurs salons rôlistes par ex, de la gestion de fichiers sur le serveur pour un historique des convs pour des échanges sur la durée entre users façon Skype...
Puisque c'est mon dada, je songe à faire le site avec mon bon vieux framework php pour l'inscription, config, affichage, etc etc. Reste le gros morceau : le chat. Qu'utiliser ?

Et là, je demande vos avis sur la question... de l'AJAX qui vérifie périodiquement les nouveaux messages ? même si c'était toutes les 3 sec, c'est peut-être léger question chat en temps réel ? installer un Node.js ? il va me falloir me pencher sur cette techno. Utiliser les websockets ? est-ce sûr, et suffisamment accepté par les navigateurs ?
Je ne pense pas qu'il y ait de bonne ou mauvaise solution, simplement beaucoup de choix avec des avantages et des défauts. Si vous avez des solutions particulières à mettre en avant et des arguments justifiés...
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

2

3

Il me faudra bien finir par me mettre au développement full-js aujourd'hui, et non plus comme un code client complémentaire à mon appli php. Le full-js m'inquiète un peu du fait de ma connaissance superficielle (du moins je l'imagine) du vanilla.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

4

pour les websocket il y à des fallback, en node regarde du coté de socket.io http://socket.io/demos/chat/
et la le mec il le pécho par le bras et il lui dit '

5

Tu peux aussi décortiquer comment fonctionnent les sites de chat existants, genre Mibbit.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

6

Mibbit, comme le chat que j'utilise, sont en fait des clients IRC déguisés.
Il y a un côté dev perso aussi, où je veux pouvoir concevoir par moi même pour contrôler et apprendre. IRC est une manière de contourner le problème, ce que je veux aussi apprendre ainsi est un moyen de faire des applis en temps réel.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

7

Oui je sais que c'est de l'IRC, je parlais de regarder comment ils font la récupération des messages entrants (AJAX, websockets, etc.)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

8

Pas facile, Mibbit n'est pas open-source.

Mais tout en gardant PHP, je vais me pencher sur les websockets. Si PHP ne les gère pas encore nativement, il existe déjà des librairies qui le font, ainsi que des modules Apache par exemple.
Je peux de toute façon commencer à coder l'ensemble de mon application et faire des POC du chat par la suite, le dialogue en temps réel étant un élément à part du site. Je vais me fermer à quelques vieux IE, mais qu'importe.

En revanche je garde Meteor dans un coin pour faire des tests, j'en entends du bien. Et surtout "de la simplicité". Parce qu'Angular, Backbone...
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

9

Websocket a été complètement fait pour ce genre d'usage, ça me semble la solution la plus logique techniquement, même si elle est, il est vrai encore jeune. Pour ce qui est de la compatibilité a priori ça marche depuis un bon moment sur tous les bons navigateurs et depuis la version 10 sur IE.
Il me semble qu'une solution pour faire du temps réel avec de l'ajax serait de faire envoyer une requête ajax par le client qui attend les messages. Le serveur la conserverait ouverte en suspend jusqu'à ce qu'il ait réellement quelque chose a envoyer. Par contre je n'ai jamais eu l'occasion de la mettre en pratique.

Par contre moi, les mots PHP et JavaScript me donnent des boutons et vu que c'est visiblement ce tu apprécies, je me garderais bien de te conseiller un framework.
avatar

10

On ne peut pas ouvrir une requête AJAX en attendant une réponse, à moins d'annuler tout timeout sur le serveur. À la rigueur sur un vieux IE, un fallback avec un appel AJAX toutes les 5sec pourrait suffire (à moduler selon le nombre d'utilisateurs IE<10), c'est moins interactifs mais ça peut passer.

Pour PHP et JS, comme je l'ai dit ce sont mes outils de travail, je sais ce que je fais :3 ce n'est pas nécessairement ce que j'apprécie, mais j'en connais les écueils à éviter. On a déjà bien des discussions là dessus sur le topic Mon langage est meilleur que le tien.
Par curiosité, existe t-il des langages (langages, pas frameworks) qui gèrent nativement les websockets ? si on exclut les langages qui sont actuellement en v0.0012 alpha pre-release ?
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

11

pourquoi ne pas poller le serveur en ajax?

12

Qu'entends-tu par poller ?
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

13

while(true) {
send ajax(t'as un msg pour moi, clientid)
si pas timeout et j'ai des données {
ajouter texte a la fenetre de chat
}
}

14

Une requête AJAX ouverte, même pendant un moment limité par le timeout, ne va t-il pas y avoir un problème si un grand nombre de personnes attendent ainsi ?
Les websockets font qu'ils acceptent des connexions sortantes/entrantes parce qu'ils savent où aller, et n'ont pas besoin de pinger en permanence. Mais ces AJAX ouverts constituent des appels en attente au serveur, je me demande s'il n'y a pas un problème à terme du nombre de connexions simultanées au serveur si X personnes attendent en permanence une réponse ?
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

15

je me pose la question aussi, mais les websockets et autres systemes de notifs ne font pas ca eux aussi?

16

Meowcate (./10) :
On ne peut pas ouvrir une requête AJAX en attendant une réponse, à moins d'annuler tout timeout sur le serveur. À la rigueur sur un vieux IE, un fallback avec un appel AJAX toutes les 5sec pourrait suffire (à moduler selon le nombre d'utilisateurs IE<10), c'est moins interactifs mais ça peut passer.
Tu pourrais faire que le client lance une nouvelle requête AJAX avant le timeout de la précédente. Ça serait déjà plus économe qu'un refresh toutes les 5 secondes et ça devrait être plus réactif.
Meowcate (./10) :
Par curiosité, existe t-il des langages (langages, pas frameworks) qui gèrent nativement les websockets ? si on exclut les langages qui sont actuellement en v0.0012 alpha pre-release ?

C'est typiquement le genre de truc qui n'a rien a faire dans un langage, ou alors dans la bibliothèque standard, mais pas dans le langage même.
Après entre le "langage" et le "framework", il y a la bibliothèque qui fait son boulot et rien de plus. Vu que tu maitrise le PHP Ratchet a l'air d'un bibliothèque correcte qui gère le Websocket.
avatar

17

Uther (./16) :
Tu pourrais faire que le client lance une nouvelle requête AJAX avant le timeout de la précédente. Ça serait déjà plus économe qu'un refresh toutes les 5 secondes et ça devrait être plus réactif.

Mais mon serveur maintient alors une connexion "en attente" pour tout utilisateur fonctionnant de cette façon, n'est-ce pas moins productif que des requêtes fréquentes (12 par minute) mais qui ne durent qu'un instant ? (de l'ordre de la dizaine de ms)
Uther (./16) :
C'est typiquement le genre de truc qui n'a rien a faire dans un langage, ou alors dans la bibliothèque standard, mais pas dans le langage même.

Pourquoi pas, dans le cas d'un langage conçu pour le web ? PHP gère bien nativement les headers, les fichiers uploadés, les sessions...
À côté, si question code je mets pour sûr Perl ou Python au-dessus de PHP, ce sont des langages qui "peuvent" faire du web, pas qui ont été "conçus pour". C'est sans doute pour cela que malgré toutes ses casseroles PHP est un langage très populaire dans la conception web.
(d'avance : ce qui ne veut pas dire que reléguer ces fonctionnalités à des libs ou framework est une mauvaise chose)
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

18

Jamais l'expresison "Internet est fait de chats" n'a ete aussi juste que ce topic...

#loin#

Sinon utiliser IRC comme backend n'est pas un cache misere bien au contraire
1 -> ca permet d'utiliser des clients IRC classique pour participer au chat, il y a des cas ou il est plus pratique d'avoir un client dedie qu'une page web
2 -> les serveurs IRC sont capable simplement de faire du clustering pour la monte en charge, les clients se connectent de manière transparente a plusieurs serveurs lie entre eux
3 -> on a beau dire, mais le protocole IRC est assez robuste, supporte pas mal de fonctionnalité (multicanal, administration/maintenance via des bots etc..)

La pluspart des chats en ligne que j'ai pu voir qui n'etait pas base sur IRC en backend etait generalement beaucoup plus lourd et lent que les version utilisant IRC.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

19

Meowcate (./17) :
Mais mon serveur maintient alors une connexion "en attente" pour tout utilisateur fonctionnant de cette façon, n'est-ce pas moins productif que des requêtes fréquentes (12 par minute) mais qui ne durent qu'un instant ? (de l'ordre de la dizaine de ms)
Tout dépend quel est ton facteur limitant, si ton serveur web ne sait pas gérer trop de connexions en parallèle, en effet mieux vaut ta méthode. Si ton serveur le supporte, ma méthode devrait permettre d'avoir une meilleure réactivité.
Meowcate (./17) :
Pourquoi pas, dans le cas d'un langage conçu pour le web ? PHP gère bien nativement les headers, les fichiers uploadés, les sessions...
Et c'est en partie pour ça qu'il est si mal branlé, il a commencé en empilant plein d'idées au fur et a mesure sans plan général.
Théoriquement dans un langage pensé pour le Web, pourquoi pas, je demande a voir, mais je ne m'imagine pas une manière propre d’intégrer les websockets de manière plus propre qu'un bibliothèque dans un langage existant.
avatar

20

Je dirai bien "en fusionnant la lib au langage", mais au jour d'aujourd'hui non en effet, le websocket est encore trop jeune ne serait-ce que par les différentes versions du protocole.
Quant à IRC, comme je l'ai dit plus haut je me force à coder le chat moi-même, du fait que c'est aussi un moyen de faire des essais sur les applis en temps réel en général.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

21

raz le bol de libs fusionnées aux langages!

non sérieux, ca n'ajoute rien de "fusionner", ca ne fait que rendre le parseur plus complexe sans aucun avantage.

toutes les fonctions de php ne sont pas "fusionnées au langage", c'est juste que la lib standard php est tres grosse et disponible par défaut sans besoin de commandes "import"

22

squalyl (./11) :
pourquoi ne pas poller le serveur en ajax?

Ça peut être super coûteux (genre tu as du SSL + kerberos…).
Meowcate (./10) :
Par curiosité, existe t-il des langages (langages, pas frameworks) qui gèrent nativement les websockets ? si on exclut les langages qui sont actuellement en v0.0012 alpha pre-release ?

Pas à ma connaissance. Il commence à avoir des solutions de contournement utilisable dans certains frameworks. Par exemple pour Django (seul framework que je connaisse réellement, désolé), il y a une solution qui passe par un redis intermédiaire.
En gros, tu as un tout petit code Python qui fait l'interface entre le websocket et un Redis (le code écrit dans le Redis ce qu'il lit sur la socket, et vice-versa). Derrière, tu as plusieurs threads qui vont lire le Redis et traiter les tâches (avec potentiellement des appels bloquants).

Le même principe doit être facile à faire avec du RoR ou du Play, si ce n'est pas déjà fait.

À côté de ça, il commence à y avoir un débat pour intégrer nativement HTTP/2 et les ws dans Django.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

23

en php suivant le nombre de worker configurés dans le serveur web ca risque d'être fun, en node par contre tu pourrais avoir un nombre quasi illimité de clients connectés à la fois

> le websocket est encore trop jeune ne serait-ce que par les différentes versions du protocole.
d’où l'utilité de passer par une lib le wrapant, comme socket.io, il se connecte sans utiliser les websockets puis upgrade la connexion pour les utiliser si le client le supporte

c'est assez fun à utiliser et vraiment réactif en plus d'être super simple (et super stable), si tu veux voir ce que ca donne en "vrai" tu peux tester par exemple ce truc que j'avais fait il y à qq temps (demo

ensuite tu n'es pas forcé de faire tout ton projet avec node, même si express rend les choses vraiment simple, configure ton serveur web pour faire un reverse proxy sur ton app node (lancé avec forever) pour les demandes d'un répertoire /chat ou autre
et la le mec il le pécho par le bras et il lui dit '