niahoo a écrit :Trop de trucs à mon avis.
Sephi-Chan a écrit :Idem. Je trouve cette stack trop importante et hétérogène : tu dois pouvoir rationaliser tout ça.
Voilà, c'est ce que je trouvais aussi.
Sephi-Chan a écrit :As-tu ai vraiment besoin de tout ça ?
J'ai "besoin" de toutes ces technologies (si on veut), mais le trop grand nombre de langages me rebute aussi ..
niahoo a écrit :Déjà, Rails. C'est écrit en ruby et pas en PHP donc on n'a pas il me semble 1 thread par requête. Tu peux avoir des objets persistants je pense non ? Ou du moins, tu as tous les outils qu'il faut pour gérer des queues, puisque tu ne cites que cette fonctionalité dans ce sujet.
Là tu vois, ça m'intrigue (pour la persistance des objets et les requêtes) .. Pour le truc des queues, je suis d'accord avec toi, il en existe (Resque et ResqueScheduler entre autre), mais bien que le fonctionnement se ressemble (queues, workers et tâches) ce n'est pas exactement le même but visé par le moteur de persistance.
niahoo a écrit :Erlang: Si le but est de lancer des queues erlang depuis Rails, et de mettre mongoDb à jour depuis erlang, erlang a les pilotes qu'il faut pour s'y connecter directement. Ensuite il y a des librairies pour communiquer entre erlang et ruby. Je ne sais pas si communiquer par HTTP est un bon plan. Mais pourquoi pas.
Oui, il y a bien des librairies (erlectricty et autres, si je ne m'abuse), mais ce n'est pas nécessaire. Parce que en fait, Erlang et Ruby n'ont pas à communiquer, et ne le feront pas (ou du moins, indirectement).
Il faut savoir que les actions du joueur sont traitées tout d'abord par Rails (après avoir passé par l'intermédiaire du client javascript). Généralement pour enrayer les erreurs / tentatives de hack, ou peu importe. Le fait est que, pour ce qui a trait au jeu lui-même, Rails ne fait rien (d'où le principe des queues). Rails enregistrerait, en base de données disons, dans la bonne queue l'action à traiter, et le moteur Erlang le ferait (que ce soit immédiatement, ou de façon asynchrone, avec un délai dans le temps).
Rails aurait tout accès aux données du jeu quand même (pour les classements), et n'embêterait pas Erlang pour les modules extérieurs (du genre blog, forum, wiki, etc). Dans ces cas-là, les actions seraient traitées directement par Rails.
niahoo a écrit :Enfin, Node. Je pense que coupler Rails et erlang est un bon plan, rails sert tout le HTML et erlang tout le JSON. Et node aussi je pense, si tu es plus à l'aise en javascript ça peut être mieux, mais erlang est très sympa à découvrir (le langage s'apprend très vite, le framework est plutôt complexe je trouve.)
Dans les deux cas, Node ou Erlang, tu pourras gérer des queues (nickel pour erlang car tu auras une API synchrone), tu pourras faire du push avec socket.io ou sockjs. je pense que Erlang + Node c'est une mauvaise idée, tu iras plus vite avec un seul (et tu pourras faire du push depuis les queues ça peut être pratique ^^).
S'il y en a un à balancer, c'est définitivement Node.js selon moi. Mais, d'où mon interrogation, dans ce cas-là Juggernaut peut-il tout effectuer seul? (pour le push et tout le tatim)
Oups, j'ai manqué un bout.
niahoo a écrit :edit: hhmmm pas très clair tout ça .. sorry
J'ai pu me débrouiller, c'est pas trop pire
niahoo a écrit :Quelques remarques :
Avec erlang, y a pas de framework web du niveau de rails. Pour servir du HTML c'est pas encore ça (y a quand même de super trucs, mais pas trop adaptables pour un jeu je pense). Bon, tu ne comptais pas le faire.
Oui, d'où le fait que je ne peux pas tout simplement utiliser Erlang pour l'intégral. Mais bon, ça fait un peu mon affaire. Et puis Rails est génial aussi.
niahoo a écrit :Erlang dispose de serveurs web parmi les plus rapides qui existent. Pour faire du push sur 2 - 3 URL c'est impec.
Bon pour node je sais pas mais j'ai l'impression qu'il y a beaucoup plus de tutos et de doc.
Ah, là tu vois, je savais pas; on peut faire du push avec Erlang? Tu as des liens/noms pour ces serveurs?
J'ai pas trop compris le truc des 2-3 URL par contre.