Supernova - a telnet comet proxy for miniTruco!
Sandro Gasparoto
bem, como já havia te antecipado, está lançada a primeira versão de um
telnet comet proxy para o miniTruco! Andei pesquisando e achei que o
Orbited (http://www.orbited.org) me parecia uma plataforma muito boa
para o que estávamos buscando, escalável e bem poderosa, aguentando
conexões comet na casa dos milhares, de acordo com os desenvolvedores.
Dessa maneira, acabei desenvolvendo uma espécide de "proxy" que roda
em cima dessa plataforma gerenciando todas as conexões telnet ao
servidor do miniTruco, que acabei batizando de "Supernova"... (ok, eu
sei... nada imaginativo...). Fique à vontade para baixar do trunk
principal em http://code.google.com/p/supernovatelnetcometproxy. As
instruções estão em "readme".
Agora acredito que ficará bem mais fácil desenvolver clientes em
DHTML/Javascript fazendo uso do Supernova como middle-tier. Estava
pensando em começar com uma espécie de "widget" universal para Orkut,
Facebook, blogs, o que vc acha? O código javascript básico poderia
inclusive ser reutilizado para outros "front-ends" no futuro também...
se alguém se habilita a tocar esse projeto poderíamos fazer um
trabalho em equipe...
Ah, gostaria de dar uma sugestão... o que vc acha de incluir no
servidor de miniTruco comandos para "chat", tanto entre usuários
livres como somente entre os 4 que estão jogando? Dessa forma
facilitaria a interação de jogadores que buscam outros jogadores para
jogar, assim como entre os 4 que estão na mesa, tornando o miniTruco
bem interativo... essa seria uma "feature" bem importante para
usuários de "desktop"...
Me diga o que vc achou e o resultado dos seus testes!
Um grande abraço,
Sandro
Carlos Duarte do Nascimento (Chester)
Desculpe pela demora - essas semanas têm sido uma loucura aqui no
trampo, mudei de cargo e estou tentando balancear isso ainda.
Ainda não consegui baixar e olhar (e a prioridade vai ser adicionar a
nova versão da estratégia, o que devo fazer nos próximos dias). A má
notícia: não tem como hospedar no servidor atual. Uma idéia seria
subir pra outro lugar e fazer a comunicação remota. Outra seria ter
uma instância do servidor (ou todo ele) rodando onde rodar o
Supernova.
Sobre os comandos de chat, sim, seria uma boa. Acho que um comando
simples, do tipo "M apelido_do_destinatario mensagem", cuja
notificação seria "M apelido_do_sender mensagem" resolveria os direct
chats. Um outro comando, do tipo "B mensagem" mandaria a mensagem
(broadcast) para todo mundo na sala em que você está (a notificação
seria "B apelido_do_sender mensagem).
Dessa forma clientes já existentes podem ignorar as notificações, e
não quebramos a compatibilidade. Alguma outra idéia?
[]s,
Chester
2008/5/15 Sandro Gasparoto <sandro.g...@gmail.com>:
--
Carlos Duarte do Nascimento (Chester)
c...@pobox.com
Sandro Gasparoto
desculpe-me pela demora em te responder, estou reformando minha casa e
vc sabe, uma dor de cabeça danada!... estava sem acesso a Internet
também... mas agora já estou novamente "no ar".
Achei legal sua sugestão dos comandos de chat, muito legal mesmo, por
favor nos informe assim que vc já tiver algo!...
Qto ao supernova, ok, sem problemas, vou instalar em uma máquina em
casa mesmo, e este servidor se comunicaria remotamente com o servidor
oficial do miniTruco. Ideal para testes. Aí já daria para começar a
dar forma ao zTruco. Te manterei informado!
Um grande abraço,
Sandro
2008/6/10 Carlos Duarte do Nascimento (Chester) <ches...@gmail.com>:
--
Sandro Rodrigo Gasparoto
36 Riseley Road
Maidenhead/Berks
SL6 6EP - United Kingdom
Mobile: +44 (7739) 226386
1840 W. Whittier Blvd #1350
La Habra/CA
90631 - United States
Carlos Duarte do Nascimento (Chester)
Curiosidade: ontem eu arrumei um problema que o servidor teve desde a
semana passada: a máquina foi formatada e passou a usar o gij ao invés
da JVM da Sun. A aplicação funcionava direitinho, mas o gij estava
reclamando que a classe Carta importava duas classes midp - mesmo
considerando que ela nunca usa essas classes quando o jogo roda
server-side.
Aparentemente, a JVM da Sun só carrega efetivamente a classe quando
ela é referenciada, e o gij é um pouco mais "eager". Mas bastou
adicionar as classes "dummy" do SDK da Sun (i.e., embutir o conteúdo
do midp.jar no miniTrucoServer.jar) que ele sossegou.
Aí, claro, aproveitei para implementar os comandos abaixo. Não fiz tag
da versão nem atualizei o texto com o protocolo do servidor pra dar
margem a mudanças eventuais que se façam necessárias - como até agora
a coisa é 100% compatível backward (se os clientes tiverem seguido a
diretriz de ignorar notificações que não conheçam), a gente pode ir
experimentando.
Dois detalhes:
- Os comandos funcionam apenas dentro de uma sala (a idéia é que as
conversas ocorram dentro da sala). Talvez o M (mensagem privada) possa
rolar fora, mas se desse pra ficar dentro ia simplificar tanto a
implementação back-end, quanto uma futura adaptação do cliente J2ME;
- O cliente J2ME (i.e., o próprio miniTruco original) por ora ignora
essas notificações. Ainda preciso pensar num esquema para exibi-las na
tela do celular (os balões são meio limitados em tamanho, e só
aparecem quando o jogo está rolando), mas isso fica pro próximo round
de updates (quando pretendo resolver o problema dos celulares em que o
menu "atropela" as cartas da parte inferior e outros detalhes
pequenos).
[]s,
Chester
2008/6/23 Sandro Gasparoto <sandro.g...@gmail.com>:
Sandro Gasparoto
Estava pensando sobre os comandos de chat... penso que o comando proposto B realmente seria muito útil, mesmo caso usuários não estivessem em uma mesa jogando. Dessa forma, usuários poderiam conversar e combinar para entrar em uma determinada sala para jogar.... Agora o comando M, que seria permitido somente quando o usuário estivesse em uma mesa, enviaria mensagem a todos dessa mesa apenas. Comandos para mensagem privadas não vejo como uma coisa legal... permitiria usuários explicitamente comunicarem aos parceiros quais cartas possui por exemplo, meio que "sacaneando" o jogo...
Portanto minha sugestão seria:
Usuário na sala de espera: B <msg> permitido, M <msg> negado
Usuário em uma mesa: B <msg> permitido, M <msg> permitido
Implementações de clientes poderiam fazer uso desses comandos e saber tipo quando uma mensagem é para o chat "sala de espera" e quando é para o chat da mesa de jogo, também, dando tratamento diferenciado e melhorando o aspecto final da implementação.
O que vc acha?...
Abraço,
Sandro
Carlos Duarte do Nascimento (Chester)
Sim, faz todo o sentido. Na verdade, pensando nessa linha, me questiono se, mesmo fora da mesa/sala, é uma boa idéia ter mensagens privativas. Acho legal que elas sejam direcionadas (i.e., eu possa dizer algo especificamente para uma pessoa), mas seria bacana se elas fossem visíveis a todos (evitando "combinações do mal").
Para isso, teríamos um simples comando "B", para mensagens públicas, direcionadas ou não, dessa forma:
B usuario mensagem
Onde "usuário" pode ser um nome (ou uma posição na sala atual, traduzida para um nome no retorno) ou * para representar todos os usuários na sala atual (ou todos os usuários fora de sala, se o usuário atual estiver fora da sala). A mensagem seria sempre pública, mas a notificação informaria o destinatário.
Ex.: estou eu, você e o zé numa sala. Se eu dou
B sandro teste 123
você *e* ele recebem a notificação "B sandro teste 123" (e o cliente traduz para algo como "Chester diz para Sandro: 'teste 123")
Se, por outro lado, eu mandar
B * teste 123
ambos recebem "B * teste 123" e exibem "Chester diz: 'teste 123"
Se eu estiver fora da sala, as notificações são as mesmas, mas vão para os outros que estão fora da sala.
Poderíamos também ter mensagens privativas, mas creio que esse esquema é mais "gregário" (e podemos adicionar o M no futuro).
O que você acha?
[]s
Sandro Gasparoto
gostei muito do modo que vc descreve o comando B abaixo. Acho que é isso mesmo! Simples, eficaz e fácil de ser implementado.
Abraço,
Sandro