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

Eden Cardim edencardim em gmail.com
Quarta Junho 4 13:41:06 PDT 2008


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".

-- 
edenc.vox.com


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