[Rio-pm] Lendo conteúdo de página remota

Alexandre Nascimento listas.news em gmail.com
Quarta Junho 18 21:59:18 PDT 2008


Amigos,

Demorei um pouco, desculpe...

Agradeço a todos pela colaboração e sugestões, realizarei diversos testes
pois agora tenho o real ambiente montado e irei ler apenas um texto em uma
URL, exemplo para esclarecimento:

Acesso o endereço http://host/status e é exibido uma página com o texto
Serviço=Ok.

Obrigado mais uma vez a todos.

Alexandre

Em 05/06/08, Marcos Machado <listas em istf.com.br> escreveu:
>
> Eden,
>
> Acho que já fico clara nossa diferença de ponto de vista. Obrigado pela
> discussão construtiva. São conversas assim que me deixam satisfeito por
> participar desse grupo.
>
> Um abraço!
>
> []s, MM
>
>
> Eden Cardim escreveu:
>
> > 2008/6/4 Marcos Machado <listas em istf.com.br>:
> >> Se você é um fã do Mechanize, me desculpe, mas para o que ele pediu isso
> >> é overkill.
> >
> > Não sou "fã" do Mechanize, mas sou fortemente a favor do reuso de
> > código comunitário porque foi assim que o perl chegou onde está hoje e
> > é o único motivo pelo qual perl é uma solução viável para um negócio.
> >
> >> A sugestão do Mechanize parece ter sido influenciada pelo fato do
> >> servidor estar ouvindo na porta 80.
> >
> > E pelo fato do endereço especificar o protocolo de transporte.
> >
> >> Ou você iria sugerir que ele instalasse o Apache do outro lado para usar
> >> o Mechanize do lado de cá? Eu acho que estamos nos aprofundando demais
> >> em uma sugestão sem conhecer a real necessidade.
> >
> > Não, existem outras soluções de servidor web mais lightweight. Mas
> > isso não vem ao caso, o problema inicial dele pediu http e por isso
> > parte-se do pressuposto de que há um servidor http escutando do outro
> > lado.
> >
> >> Claro, a parte do meu sistema que trata esse conteúdo não é do interesse
> >> da lista. Isso acontece quando enviamos "exemplos básicos" que poderão
> >> ser incrementados de acordo com a necessidade.
> >
> > Robustez é requisito de qualquer solução que não seja um exercício
> acadêmico.
> >
> >> Quando quaisquer desses problemas levantados aparecerem, o fato de abrir
> >> um socket ou usar o Mechanize não me parece fazer nenhuma diferença. Ou
> >> o Mechanize utiliza alguma magia negra para se conectar em um servidor
> >> que não existe?
> >
> > Não, mas ele trata os casos excepcionais automaticamente.
> >
> >> A parte de conexão dele é construída sobre o LWP que usa IO::Socket
> >> (sim, eu acabei de checar!) só acrescentando uma enorme camada de opções
> >> que podem ou não serem úteis.
> >
> > Isso não é relevante, módulos e API's existem para encapsular código e
> > você não precisar se preocupar com esse tipo de coisa.
> >
> >> Minha "solução" (se é que podemos chamá-la assim, pois não passa de uma
> >> sugestão simples) está funcionando em mais de 50 sistemas diferentes, em
> >> um contexto bem grande, sob as mais adversas condições de rede, e todos
> >> os problemas dessa natureza são tratados de forma bem elegante.
> >>
> >> Quer ver um exemplo que me deu dor de cabeça? Sabe aqueles \r\n\r\n do
> >> final da requisição GET? Pois é, se usarmos só um \n funciona
> >> maravilhosamente bem para a maioria dos servidores web. Só que em alguns
> >> ambientes, que estão atrás de certos tipos de proxy transparente, essa
> >> requisição estava dando timeout.
> >>
> >> Cerca de uma hora foi o tempo que levei para descobrir (via comparação
> >> byte a byte de um dump da conexão) qual a diferença do meu socket para
> >> uma requisição do wget.
> >
> > Olha o "false laziness" aparecendo aí, somando essa 1 hora com o tempo
> > inicial já temos mais de uma hora pra implementar um requisito
> > trivial.
> >
> >> O Mechanize resolveria? Sim, resolveria. Mas essa questão não é
> >> resolvida por ele e sim pelo LWP, neste trecho, que está escrevendo no
> >> socket:
> >>
> >> <code>
> >> print $sock join("\015\012" =>
> >>        "GET $path HTTP/1.0",
> >>        "Host: $netloc",
> >>        "User-Agent: lwp-trivial/$VERSION",
> >>        "", "");
> >> </code>
> >
> > Isso não é relevante, módulos e API's existem para encapsular código e
> > você não precisar se preocupar com esse tipo de coisa. Mas tudo bem,
> > admito que algum sabor do LWP seria mais adequado pra esse caso.
> >
> >> Isto resolvido, voltei para casa feliz, já que só precisei atualizar um
> >> script ao invés de instalar o Mechanize e seus pré-requisitos em 50
> >> servidores (alguns deles com sérias restrições de espaço, memória e
> >> processamento).
> >
> > Se a solução inclui implantação homogênea em 50 servidores diferentes
> > então seu problema mudou de foco, e não é culpa dos módulos que você
> > usa. A hora que você gastou resolvendo o problema dos newlines você
> > poderia ter usado para montar um sistema de arquivos remoto com o
> > WWW::Mechanize e suas dependências (que são todos perl puro), por
> > exemplo. O espaço total ocupado por ele e suas dependências é de 3.8
> > MB sem compressão, e a execução de *todos* os testes consumiram 2.28
> > segundos da minha CPU virtual, se isso é um problema, então suas
> > restrições de espaço e processamento são *muito* mais do que sérias. O
> > custo de 20 horas de um bom desenvolvedor talvez seria o suficiente
> > pra resolver o problema do hardware e o empreendimento ainda teria um
> > aumento do seu patrimônio líquido.
> >
> >> Mas, como já disse, não temos os pré-requisitos da solução, motivo pelo
> >> qual prefiro sugerir por baixo e ir crescendo só o necessário.
> >
> > Eu prefiro o que for consumir menos recursos do projeto. Prevenção
> > gratuita nunca é ruim desde que não ocupe um desenvolvedor por muito
> > mais tempo do que ocuparia com as soluções "mais simples".
> >
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Alexandre
SlackUser

"Seja Livre, Use Linux!"
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/rio-pm/attachments/20080619/b25d8b77/attachment.html 


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