Lors du Django Meetup Paris numéro 2 (qui a eu lieu dans les locaux de 20 minutes, merci à eux pour le prêt de la salle (et à Julien pour l’orga) ), un petit récap des confs EuroDjango a été fait par Samuel (le frère de David, et oui un Paccoud peut en cacher un autre!!). Apparemment un des sujets porteur des EuroDjango avait été le ‘web temps réel’ (ce que je déteste ce terme tiens … temps réel, ça a un sens.. ça ne veut pas juste dire un truc en mode connecté) et la mise en place de celui ci dans Django (et du fait que peut être notre framework adoré n’était pas super en avance sur ce sujet).
J’en ai profité pour donner mon avis sur la question. A savoir qu’à mon sens, les serveurs webs n’était pas fait du tout pour gérer des connexions en mode connecté. Parce qu’ils n’ont pas été prévu pour cela. Idem pour le cœur de django qui n’est pas fait pour garder des pools de sockets, des états par connexion clientes, etc etc …
Alors qu’à contrario il y a des frameworks (je pense à twistted mais pas seulement) ou des manières d’écrire des serveurs qui permettent de gérer proprement des communications en mode connectées.
Il me semblait donc logique de ‘sortir’ la partie websocket du cœur de Django pour qu’elle soit gérer par ‘autre chose’. Il me semble qu’à la fin de ma tirade explicative, quelqu’un m’a dit ‘ben ok, fait le’ (me demande même si ce n’est pas ce fourbe de n1k0)
Du coup, ben ayant eu un peu de temps, ces jours-ci, j’ai rapidement fait un proto merdique de test.
Le principe a été de prendre l’exemple de simple chat de Gevent-SocketIO et de le ‘transformer’ en une commande de management Django. La commande de management simulant un serveur de gestion des connexions socketIO des utilisateurs. Du coté django, on a une première vue qui demande de donner un nickname puis on se retrouve sur la fenêtre de chat (qui utilise socketIO) et on peut discuter avec les autres connectés. J’ai rajouté deux petits trucs, pour le plaisir, le fait d’avoir les 5 dernières lignes de discussion (ça se récupère par la partie WebSocket) et le nombre de user et lignes de discussions totales (s’affiche la première fois par la connexion HTTP classique, se met à jour par les WebSocket)
Il faut donc à un moment ou un autre, lier la partie DjangoWeb de la partie SocketIO. Comme ce n’est qu’un prototype pour m’amuser, je passe à la vue de chat une key généré aléatoirement, key que me renvoie le client JS à travers la websocket.
Bon, bien entendu, tout cela n’est qu’un prototype pour expliquer (avec du code) la manière dont je voyais les choses. Bien entendu bis, il faudrait ‘lier’ la partie Web classique et Websocket d’une meilleure façon, ne pas utiliser une commande de management brute de décoffrage, potentiellement élaguer pas mal gevent-socketio pour enlever tout ce dont on n’aurait pas besoin, etc etc …
Mais voilà, j’avais juste envie de faire un test, d’en parler ici et de vous demander votre avis sur la question:)