Obrigado, vou consertar já já

[ ]s, gc

Abs,

Matheus

E em relação a todos os questionamentos, eu poderia dar várias respostas mas o comentário do Rafael Ferreira foi excepcional: existem várias maneiras de fazer a mesma coisa e cada uma delas pode ser mais apropriada em uma determinada situação.

[ ]s, gc

http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
http://bitworking.org/news/380/bloom-filter-resources

Muito interessante sua idéia e com certeza uma prova de conceito pode ajudar bastante a esclarecer a questão da escalabilidade.

Problema é querer escalar e ainda ter controle rígido sobre os dados. É basicamente o quanto General confia no Coronel, que confia no Major, que confia no Capitão, que confia no Tenente que instrui os aspiras pra executar as instruções lá de cima.

Basicamente, quem não confia, não escala.

Abraço.

Em relação à abordagem push, qual a vantagem, se pelo que você diz haveria um problema de escalabilidade, que era o que você provavelmente estava tentando resolver com o push? Ou era só a questão da eficiência (menos tráfego de rede)? Ao meu ver, a única vantagem (fora a rede) é que você receberia a notificação um pouco mais rápido, já que não teria que esperar o intervalo do polling.

O polling não (necessariamente) é tão custoso, pois o HTTP tem mecanismos de verificação de alteração de um recurso. Se, por exemplo, você pudesse (não conheço a API do Twitter) criar uma busca pré-definida e associá-la a uma URL ‘GET’, o seu robô poderia, antes de solicitar o conteúdo da busca, perguntar ao servidor quando foi a última ‘alteração’, isto é, qual foi a última vez que alguém escreveu tal palavra. Esta requisição envolve apenas os headers, então você economiza bastante tráfego, e utiliza a arquitetura ‘pull’, que teoricamente é bem mais fácil de escalar.

Certo, mas uma coisa é que solução permite uma melhor escalabilidade, outra coisa é que solução é a mais apropriada. Digo, quando você tem alguma possibilidade de decidir como a coisa é feita do outro lado, claro. Quando você utiliza um serviço como o Twitter, você é um mero usuário, e pode apenas aceitar a API que eles fornecerem.

Porém, quando a escolha é sua, que arquitetura utilizar? Essa sim é uma pergunta interessante

Eu já trabalhei uma vez com algo deste tipo, e acredito que o critério mais apropriado é: o maior interessado deve ter o controle.

Se o maior interessado é quem, requisita a informação, ele deve poder fazer o ‘pull’, pois em caso de falha no sistema que fornece a informação, o requisitante pode simplesmente perguntar de novo quando este voltar, ao invés de ficar dependendo da capacidade de recuperação do outro (mensagens e eventos perdidos).

E, se o maior interessado é do fornecedor da informação (ele quer te vender alguma coisa, por exemplo), aí sim o sistema deveria ser ‘push’, já que o ônus da recuperação e reenvio de mensagens perdidas seria feito pela parte mais interessada.

A vantagem de deixar isto para a parte mais interessada é que a chance é maior dela criar um esquema mais confiável de recuperação de falhas. E também, quando você é a parte mais interessada, e possui o controle da situação, você pode ‘dar um jeito’ bem mais facilmente, em caso de falha da outra ponta.

Mas no fim, é claro, ‘depende’