Investigate Pusher for server to browser messaging

[tsimbalar]

We should have no problem using regular HTTP calls from the browser to the server (for instance to submit a score, or notify we are leaving) , but notifying from the server to the browser is more tricky, as not so many hosting providers allow to keep a connection open forever (i.e. cannot use "regular" websockets) (see issues http://groups.google.com/group/play-framework/browse_thread/thread/41a4f317b15abbc4?pli=1 or http://multikoop.blogspot.de/2012/01/playing-with-websockets.html ).

It looks like Pusher may be an option .

We need to :

• investigate how Pusher works and see if it would fulfill our requirements (limitation and pricing depending on our usage ...)
• see if it can be used with Heroku as advertised : (https://addons.heroku.com/pusher)
• find some server-side API that would be compatible with our dev stack. A few Java-based are listed on the official Pusher website... I also found a gist in scala which we could use for inspiration. After all, those are just wrappers around the HTTP calls to the Pusher RESTful API ...

This is related to issue #5 support for webSocket-less browsers

[tsimbalar]

Copie de l'email au sujet de l'utilisation possible de Slanger :

J'ai un peu regardé les histoires de WebSockets et tout et tout ... Il semblerait que l'option gagnante soit un truc du style Pusher ... i.e. : côté serveur, si on veut envoyer un truc au browser, on l'envoie en fait aux serveurs de Pusher ... Dans la page html envoyée au browser, on référence des fichiers js hébergés chez pusher ... à partir de là, le browser écoute les messages venant de chez pusher, qui sont en fait les messages que le serveur lui a envoyés ...

C'est pas trop mal, Pusher fournit déjà des apis js qui gèrent les cas les plus courants ... par contre, comme je n'aime pas trop dépendre d'un service tiers, j'ai trouvé en cherchant un truc qui s'appelle Slanger (https://github.com/stevegraham/slanger), qui est une espèce d'implémentation open source de serveur Pusher , qui peut fonctionner avec les mêmes apis clients js , et la même API serveur ... C'est une application Ruby (On Rails?) qui s'installe facilement et qui utilise par derrière Redis. C'est plutôt cool. Le gros intérêt c'est que ça permet de travailler sans connexion internet , avec une instance locale (comme moi dans le train :) ) , et de faire des tests sans devoir payer de facture à Pusher. ça veut aussi dire que si on va chez Pusher, et qu'on a des regrets par la suite (trop cher, trop chient...), on peut toujours faire marche arrière et hoster nous même la partie messaging (avec notre sysadmin de choc :P) ....

Bref, donc avec ça, il ne nous manque que les APIs Scala pour travailler ... Je suis tombé sur un gist (https://gist.github.com/1129391) avec un début d'implémentation de l'API Http/REST serveur ... et j'ai pris ça comme base pour bidouiller ....
Résultat, vous pouvez trouver un exemple d'appli Play 2.0 Scala basique qui utilise :

• l'API js de Pusher
• Slanger comme backend pour les websockets
• de la bricole faite par votre serviteur pour la partie API serveur pour voir
• de la bidouille en js pour avoir une trace des échanges de message

ça se trouve ici : https://github.com/tsimbalar/play-pusher-slanger (c'est du code pas très beau, mais j'ai pondu ça aujourd'hui alors bon ...)

jetez-y un oeil, mais je pense que tout ça veut dire qu'on n'aura pas besoin de tout jeter pour hoster chez Heroku (ou ailleurs)