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