Re: pull X push e java 1.4

[Paulo Eduardo Azevedo Silveira <PROTECTED>]

oi pessoal, roberto, nelson e tiago

em primeiro lugar, quero deixar claro que nesse caso o PULL eh MUITO pior
eficientemente do que o push, como o kon ja havia escrito no primeiro
email, e eu repeti na hora de escrever o meu email (quote: "com certeza o
pull (nesse caso) eh menos eficiente").

mas a minha opiniao eh que ele eh MUITO mais elegante, escalavel,
cutomizavel, e muitos outros bons adjetivos.

para quem quer saber mais sobre MVC, leia na pagina dos proprios criadores
do termo (sun) ...

http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html

e aqui tem um papo legal sobre pull vs push, voltado a web, mas vale em
varios casos:

http://jakarta.apache.org/turbine/turbine-2/pullmodel.html

e aqui vai uma boa citacao (e engracada) sobre o pull deixar a coisa mais
escalavel e customizavel que o push:

"Gone are the days where one would have a Java class that would be
responsible for building the context up for the template. Instead, there
would be a single base class that places the few objects into the context
for every request and there is a documented API that the template designer
can refer to in order to access the information that he/she needs to get
at. Of course this information is only retrieved when requested and can
also be managed in a cache for reuse. 

By moving to a "Pull" model, it becomes possible to more easily achieve
complete independence from the Java engineers in order to not only change
the look and feel (UI) of the site but also the information architecture
(IA) layout and flow of the site. "

a fonte eh o link anterior, um pessoal do apache responsavel por um
framework de servlets.

falou
sao os meus 2 centavos.

paulo




---------
"The software required Win95 or better, so I installed Linux."
"Standards are good! Let us have a LOT of them!"
Paulo Eduardo A. Silveira   <PROTECTED>
UIN: 5142673   www.paulo.com.br

On Thu, 21 Mar 2002, Tiago wrote:

> Nelson Posse Lago mandou bem:
> 
> > Ah, mas quem disse que o servidor do chat tem que ser o seu controller?
> 
> exato... Uma coisa é push/pull entre os hosts, outra coisa é o que vc faz no
> cliente depois que a msg chegou. Eu acho que no MVC, a coisa nao é nem push e nem
> pull: o Model avisa o View que ele mudou, e o View relê os dados do Model.
> 
> Mas essa idéia também pode se aplicar à parte cliente/servidor: se todas as
> mensagens (por mensagens eu incluo "Tiazinha entrou na sala" e coisas do tipo) sao
> numeradas, o servidor pode avisar o cliente que há novas mensagens, e o cliente
> "puxa" os dados novos. Isso sim geraria uma sobrecarga maior no servidor do que os
> dois primeiros métodos, pq inclui duas mensagens.
> 
> Mas eu me pergunto: entre um pull e o próximo, qual a probabilidade de termos
> novos dados? Gigantesca, no mínimo... no caso do chat, nao acho o pull um método
> pior que o push... a menos que se considere que o servidor tem que guardar as
> mensagens até todos os clientes puxarem. Hmmmm...
> 
> > > 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.
> 
> Mas quando vc usa push, vc ainda tem que saber quem ainda tá conectado! O CORBA se
> encarrega das conexoes, mas ele nao mantém sockets abertos pra cada cliente (ainda
> bem!). Quando ele verifica? Quando for dar push? Daí vc fica 1h conectado, e "nada
> acontece", e de repente vc manda "alo?" e lê:
> 
> "- Tiazinha saiu da sala"
> "- Johhny16 saiu da sala"
> "- ***Lili saiu da sala"
> ... todo mundo saiu da sala.
> 
> esse problema acontece com todos os métodos, desde que os usuários usem modem. Mas
> vc fica 1h sem saber que o problema aconteceu se vc usa push simples, sem nenhum
> sistema de keep_alive.
> 
> > > nao acho o push uma boa pratica de programacao para escalabilidade do
> > > VIEWER (cliente do chat) de um sistema
> 
> C queria deixar só "a tela" no cliente, né?? Dá pra fazer, mas... tem esses
> "issues"...
> 
> Ia ser legal se desse pra gente misturar server de um com client de outro, mas ia
> precisar de um padrao... acho que o professor quer que cada um crie suas IDLs,
> né??
> 
> Tudo de bom!!
> Tiago "eu sempre respondo, o que eu nao sei eu invento" Silveira
> 
>