[SP-pm] Websockets & alikes (was: Apresentando-me)

Nuba Princigalli nuba at fastmail.fm
Sun May 22 10:08:19 PDT 2011


Rafael,

On Sat, 21 May 2011 21:54 -0300, "Eden Cardim" <edencardim em gmail.com>
wrote:
> >>>>> "Rafael" == Rafael  <design.silveira em gmail.com> writes:
>     Rafael> Mas então Renato, imagine só, que até os movimentos do
>     personagem serão
>     Rafael> controlados pelo servidor. Agora sacou o porque de eu não
>     Rafael> usar http push/long polling?
>
> Dá uma olhada no APE: http://bit.ly/m6jMc2

Se quiser fazer js só no cliente, e manter as coisas em perl no server
side, sugiro o que eu estou usando aqui para updates em tempo real:
Plack::Middleware::SocketIO[1], port do Socket.IO-node [2] pro Perl pelo
vti [3]. O cliente continua o mesmo: [4].

Eu fiz uma pesquisa no início do ano, quando escolhi o Socket.IO, e li
um pouco sobre o APE. Eu preferi passar longe, e esse foi meu rationale:
Não foi pelo mérito técnico, porque me parece que ele que abordou com
carinho o problema de um comet-server, mas porque ele é uma solução
especializada demais (IMHO), que te amarra em subir um APE-server (leio
como: mais um tamagochi pra cuidar[8]) que te expõe algumas coisas em js
mas por trás tem uma js engine própria.

Em comparação, o pessoal do node.js tem uma comunidade forte [5][6], e
um perfil mais "umbrella" (all that is server-side js) e com isso acaba
acolhendo vários projetos, entre eles o Socket.IO, que propõe se virar
para te dar um "socket" com o que quer que seja suportado na ponta do
cliente (websockets, xhr, iframe, flash, whatever [7]). Pela solução
bacana, e pelo cuidado que eles tiveram em separar o client e o server
em dois projetos, já existem ports do Socket.IO server para outras
linguagens (uma delas é essa do vti [1]). Outra coisa bacana do node.js
é que estão ativamente tentando suportar outras js engines, além do
spidermonkey (e.g. rhino, v8). Ou seja, tem um ecossistema bem vivo aí,
centro de ondas que vão muito além da comunidade dos projetos node.js e
Socket.IO.

Ok, tirando o óbvio (poder continuar fazendo "use MyApp::Model; $foo
= MyApp::Model->new; $foo->kick_ass" na ponta server-side do
"socket") foi essa a impressão que ficou. Claro que cada um tem que
adaptar (ou descartar) esses pontos função do seu contexto, mas espero
que seja útil.

Happy hacking :)

Nuba

[1] http://search.cpan.org/perldoc?Plack::Middleware::SocketIO
[2] http://github.com/LearnBoost/Socket.IO-node
[3]
http://showmetheco.de/articles/2011/3/socket-io-perl-implementation.html
[4] http://github.com/LearnBoost/Socket.IO
[5] irc.freenode.net #Node.js em 2011-05-22: 567 nicks
[6] peruse [2] vs. https://github.com/APE-Project/APE_Server
[7] correlato: clkao's Web::Hippie:
    http://search.cpan.org/perldoc?Web::Hippie::Pipe
[8] ok, tive que subir um twiggy, mas, comparado com cuidar de js no
    servidor, "tá em casa".
--
Nuba R. Princigalli  nuba em pauleira.com  http://pauleira.com  @nprincigalli
Discipline is not an end in itself, just a means to an end. - King Crimson



More information about the SaoPaulo-pm mailing list