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

[Marcos Machado]

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