[Cascavel-pm] Aplicativo de chat usando AJAX + Catalyst

Nilson Santos Figueiredo Junior acid06 em gmail.com
Segunda Fevereiro 27 23:05:08 PST 2006


On 2/28/06, Breno G. de Oliveira <breno em clavis.com.br> wrote:
> gostei! Confesso que não vi muita utilidade no "fade-in", então não pude
> perceber grandes diferenças entre esse e outros bate-papos online.
> Talvez pq quando entrei tinha só eu na sala, então não deu pra ver como
> fica quando a "ação" está acontecendo...

Não é pra ter utilidade. É meramente estético. ;-)
Eu gosto de coisas esmaecendo.

> Fiquei com uma dúvida: isso é pra salas de batepapo online estilo UOL e
> derivados, pelo que vi. É possível (se é que há interesse) na integração
> disso com salas de IRC, ou com programas de mensagem instantanea (como
> ICQ/MSN)?

Sim, é possível.
Na verdade, com isso de AJAX agora, dá pra você fazer aplicativos
desktop com interface em HTML. Se você juntar isso com XUL então...

> Testei no konqueror e embora tenha funcionado, não ficou com a aparência
> tão bonita, e o tal "fade-in" não acontece (a mensagem aparece direto na
> tela depois do refresh). Segue anexo screenshot da sessão em questão,
> caso vc queira informações mais detalhadas.

O Konqueror (como tudo do KDE) adora fontes gigantescas. Mas pelo
menos funcionou. Foi um resultado melhor do que eu esperava.

> Vc diz carregar automaticamente a string que a pessoa digitou na janela
> do bate-papo sem precisar esperar o refresh após o post (mais ou menos o
> mesmo principio do IRC)? Acho que seria legal, embora tenha gente que
> prefira ter a certeza da ordem em que as mensagens chegaram ao servidor
> (e a garantia de que as mensagens chegaram na mesma ordem para todos os
> participantes da sala).

É, eu pensei nisso. É que eu dei uma olhada no Campfire (o novo
produto da empresa que fez o Ruby on Rails) e é um produto de chat
corporativo. E nele é feito assim. Não sei o que eles fazem pra
garantir a ordem (ou se garantem) mas assim que uma mensagem é
enviada, ela aparece na tela, sem esperar o servidor.

> Putz, mas isso é um problema, não??? Quer dizer, o "C" de um MVC (o que
> o catalyst se propõe) deveria ser rápido não? Especialmente capaz de
> tratar muitas requisições simultâneas via web. Se ele não consegue fazer
> isso, deve ter pelo menos um jeito de contornar esse problema (que não
> necessáriamente é do Catalyst, mas não tenho conhecimento suficiente pra
> me basear).

O Catalyst foi feito pra rodar sob mod_perl ou fastcgi, não sob CGI
normal. Com o Rails é a mesma coisa. Na verdade, acho que o Rails por
exemplo nem consegue rodar sob CGI normal.

Quando você usa mod_perl ou fastcgi o programa já fica todo carregado
na memória e, assim, não existe aquele overhead inicial do Perl
compilando o programa e os módulos pra cada request, entende? Por isso
não é um problema. Qualquer sistema sério feito em Perl deveria
utilizar mod_perl ou fastcgi, uma vez que os ganhos em performance são
*bem* grandes.

> Mais um exemplo que pode ir pro SPB mostrando como criar soluções
> poderosas rapidamente ;)

É. A programação em Perl, eu fiz *muito* rápido mesmo. Tipo, se somar
tudo, não dá umas 4 horas de programação (incluindo o tempo que gastei
lendo documentação dos módulos). Mas gastei *muito* tempo brigando com
CSS e aprendendo a escrever JavaScript orientado a objeto direito. ;-)

-Nilson Santos F. Jr.


Mais detalhes sobre a lista de discussão Cascavel-pm