[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico]
[Índice de assunto]
Re: pull X push e java 1.4
- Subject: Re: pull X push e java 1.4
- From: Nelson Posse Lago <PROTECTED>
- Date: Thu, 21 Mar 2002 16:35:04 -0300
On Thu, Mar 21 2002 at 03:08:34pm -0300, Paulo Eduardo Azevedo Silveira wrote:
> sempre que estamos usando o MVC (model view controller) para programar,
> eh altamente recomendavel usar pull, fazendo com que a parte VIEW do seu
> sistema seja mais independete ainda [...] se voce usa o push, o seu
> viewer fica amarradissimo ao controller (nesse caso o server do chat)
Ah, mas quem disse que o servidor do chat tem que ser o seu controller?
Voce pode considerar que o objeto que voce vai criar no cliente para
"conversar" com o server e' o seu "model"; esse model pode armazenar um
"buffer" com as "n" ultimas mensagens (por exemplo, n=1 pode ser bom).
Ai' voce vai ter que criar um "view" e um "controller" para esse "model".
Acho que o melhor esquema e' ter objetos do tipo:
cliente-corba
view-room
room-controller
Ai' voce faz o "room-controller" "assinar" o cliente-corba, ou seja,
sempre que o cliente-corba muda de "status" ele envia uma mensagem para o
room-controller. Ai' o room-controller pode, por exemplo, chamar um metodo
do view-room para que ele atualize o display. Acho que isso resolve o seu
problema (garantir um baixo acoplamento), nao?
O "view" provavelmente vai ter que ter um "buffer" de texto proprio para
armazenar o que esta' sendo apresentado na tela; por isso, pode ser bom
manter o "buffer" do cliente-corba com apenas a ultima mensagem. Por outro
lado, o usuario pode querer mudar o tamanho da janela, por exemplo, e para
isso seria necessario que o view armazenasse um buffer relativamente
grande. Por isso, pode ser mais "limpo" manter o buffer "grande" no
proprio cliente-corba mesmo. Nao sei o que e' melhor.
Pra dizer a verdade, o MVC e' um padrao que eu nao entendo muito bem,
entao pode ser que o que eu chamei de controller nao seja de fato um
controller; mas acho que desse jeito voce consegue ter um baixo
acoplamento entre os objetos, que e' o que voce queria.
> no pull, basta voce deixar acessivel, que o viewer pode "pullar" o que ele
> precisa / o que ele quer.
Hmmmm, isso nao parece bom; se a nada acontecer durante 1h, o viewer vai
ficar "pullando" no mesmo lugar (sem trocadilhos...) totalmente `a toa.
Agora, coloca 500 caras numa unica sala sem nenhum trafego e voce vai
gerar um load bem grande no server (e na rede!) sem necessidade. Pior: a
menos que voce "pulle" rapidinho (ja' disse *sem trocadilhos!*), vai
sempre haver um certo atraso entre o envio de uma mensagem e o recebimento
dela pelos outros.
> nao acho o push uma boa pratica de programacao para escalabilidade do
> VIEWER (cliente do chat) de um sistema
Acho que o problema que voce apontou nao e' "escalabilidade" do viewer,
mas sim flexibilidade do viewer. Mas, por outro lado, usar pull vai gerar
problemas de escalabilidade, sim, para o server (um sistema com pull e
muitas salas com certeza vai gerar muito mais carga no servidor que um
sistema com push).
Claro que falar sempre e' mais facil que fazer :-))))
Ate' +
Nelson