<div dir="ltr"><div><br>E o hash hmac ? <br>Com ele é possível autenticar sem usuário/senha... ao invés disso, é enviado o request + chave pública(ou identificacao do user) + assinatura feita com chave privada.<br></div>Isso não ajuda ?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-30 1:16 GMT-02:00 Blabos de Blebe <span dir="ltr"><<a href="mailto:blabos@gmail.com" target="_blank">blabos@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nah...<br>
<br>
A questão é que o termo REST, cunhado pelo tio Fielding<br>
(<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm" target="_blank">http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</a>), é bem<br>
específico.<br>
<br>
Tecnicamente o que a gente chama de webservice REST com json pra lá e<br>
json pra ca não bate com a definição específica de REST criada por<br>
ele.<br>
<br>
O próprio Fielding "dá piti" quando a gente chama nossos webservices<br>
de RESTful, porque não bate com o termo que ele criou.<br>
<br>
O que o Leo tá dizendo é que conceitualmente existem diferenças, e a<br>
maioria esmagadora das pessoas, não entendem isso, gerando coisas<br>
bizarras, como um webservice que se comporta como SOAP, mas porque faz<br>
PUT e DELETE "quer ser REST".<br>
<br>
No fim boa parte dessa conversa é só pra dizer se eu vou chamar o<br>
treco de bolacha ou de biscoito.<br>
<br>
[]'s<br>
<br>
<br>
<br>
2015-01-29 23:58 GMT-02:00 Solli Honorio <<a href="mailto:shonorio@gmail.com">shonorio@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> Em 29 de janeiro de 2015 21:54, Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>> escreveu:<br>
>><br>
>> Dedo gordo, continuando.<br>
>><br>
>> Olha, realmente eu não tenho interesse em rever a documentação de SOAP e<br>
>> WSDL mas estou achando essas discussão interessante porque nos obriga a<br>
>> tratar dos diferentes padrões com rigor técnico.<br>
>> Não sei se vale uma palestra, mas posso contar sobre as implementações de<br>
>> webservice que já participei, uma delas transionando em XML, outra SOAP e<br>
>> outra JSON.<br>
>> A JSON foi bem simplesinha, a SOAP nem tanto porque trabalhar no protocolo<br>
>> é exaustivo, e a XML foi uma solução caseira em 2001 bem interessante. Eu<br>
>> teria que rever alguns documentos da época para clarear a memória, era uma<br>
>> coleção de interfaces em XML para diferentes tipos de dados.<br>
>><br>
>> Continuo achando que REST é para poucos porque dá para implementar um<br>
>> webservice de várias maneiras, mas podendo participar da discussão estou<br>
>> dentro.<br>
><br>
><br>
><br>
> Continuo não entendendo esta afirmação de que REST só serve para poucos.<br>
> Neste exato momento temos bilhões de dispositivos móveis executando centenas<br>
> de bilhões de transações de milhares de aplicativos diferentes. Se isto<br>
> significa que esta arquitetura é para um nicho, então não sei o que é uma<br>
> arquitetura para a massa.<br>
><br>
> O Leonardo fez um resumo que achei interessante, REST é WEB para aplicação,<br>
> e é aí que vejo o poder deste cara. É tão simples que chega a ser<br>
> complicado, e muito leve. É muito escalável e permitir implementar a<br>
> tecnologia de autenticação mais adequado a tua necessidade. É muito simples<br>
> implementar autenticação baseado em usuário/senha (inclusive com kerberos)<br>
> via um sistema de proxy/web servicer, ou um ouath like.<br>
><br>
> O REST é o paraíso em linguagens dinâmicas, credito até que a adoção em<br>
> massa na internet só ocorreu por causa do grande número de projetos<br>
> utilizando linguagens dinâmicas (Ruby, Python, Perl) em detrimento de Java e<br>
> .Net (que alias é um pesadelo em utilizar o REST, mas parece que o Java está<br>
> melhorando este quesito segundo o Leonardo).<br>
><br>
><br>
><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>>><br>
>>> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>>> escreveu:<br>
>>><br>
>>>> Há um ponto que eu considero importante: nem todos os softwares precisam<br>
>>>> ser web/rest. Muitos softwares podem usar HTTP para fazer RPC. Até aí nenhum<br>
>>>> problema.<br>
>>>><br>
>>>> O problema, a meu ver, é fazer uma coisa dizendo que está fazendo outra,<br>
>>>> pelo fato de que a outra goza de melhor reputação. Isso é, para começar,<br>
>>>> desonesto.<br>
>>>><br>
>>>> Outro ponto que vale a pena considerar é que em tudo na vida a gente<br>
>>>> precisa estabelecer os paradigmas sobre os quais vai trabalhar.<br>
>>>><br>
>>>> Eu toparia participar de um workshop sobre RPC com Soap/WSDL sobre<br>
>>>> HTTP/XMPP/SMTP, mas creio que ainda menos pessoas se interessariam por RPC<br>
>>>> já que estudar Rest parece um investimento mais promissor hoje em dia.<br>
>>>><br>
>>>> Pessoalmente eu estou bastante interessado em Rest, em compreender e<br>
>>>> talvez em entender como modelar softwares em Rest. Em especial eu estou<br>
>>>> interessado em gestão de autenticação e autorização para implementação de<br>
>>>> SSO/ACL para o que eu entendo que é fundamental para ter um software Rest<br>
>>>> que não seja equivalente à Wikipedia em termos de ACL.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Em 28 de janeiro de 2015 16:34, Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>> escreveu:<br>
>>>><br>
>>>>> Em 28 de janeiro de 2015 11:24, Renato Santos <<a href="mailto:renato.cron@gmail.com">renato.cron@gmail.com</a>><br>
>>>>> escreveu:<br>
>>>>>><br>
>>>>>> O protocolo HTTP em si, é stateless, e trabalha em cima do TCP.<br>
>>>>>><br>
>>>>>> O TCP sim é stateful, e existe todo um protocolo complexo (ACK, Flags,<br>
>>>>>> Sequence, e window size) para que todo ele funcione.<br>
>>>>>><br>
>>>>>> Como HTTP não tem estado, ou seja, a string "GET /meu-saldo\n\n" não<br>
>>>>>> contém nenhuma informação sobre os estados anteriores.<br>
>>>>>> Mesmo com headers (cookie) e query-parameters (api-key) o HTTP-per-si,<br>
>>>>>> é stateless.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> O HTTP é stateless mas a maiorida das aplicações que rodam sobre ele<br>
>>>>> não, então implementam o mecanismo de sessão para manter o estado. O REST<br>
>>>>> não, ele propõe transações atômicas para possibilitar a otimização de<br>
>>>>> recursos, de acordo com o que vc descreve abaixo.<br>
>>>>><br>
>>>>><br>
>>>>>> O problema é acontece quando, como server, você precisar que algum<br>
>>>>>> header ou query-parameter seja enviado para algum server em especial para<br>
>>>>>> receber a resposta correta.<br>
>>>>>><br>
>>>>>> Os dados do Request HTTP deveriam poder passar por todos os proxys e<br>
>>>>>> servers sem sofrer alterações nas respostas [1].<br>
>>>>>><br>
>>>>>> Quando a aplicação recebe o HTTP e lê ele, ela deveria sempre dar uma<br>
>>>>>> resposta concisa sobre o que foi pedido, não importando do estado a<br>
>>>>>> aplicação. Ela pode ser um servidor que acabou de ligar, pode ser um que<br>
>>>>>> está rodando a horas, pode ser o ultimo request que o load-balance está<br>
>>>>>> esperando terminar antes de desligar o servidor.<br>
>>>>>><br>
>>>>>> A visão deste cookie/param tem que ser global entre os servidores.<br>
>>>>>> caso contrario, precisa usar sticky session. E sticky session é o que é<br>
>>>>>> horrível.<br>
>>>>>><br>
>>>>>> Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão<br>
>>>>>> global dos estados de cada cliente.<br>
>>>>><br>
>>>>><br>
>>>>> Eu não entendo como esses mecanismos de cache impactam a arquitetura<br>
>>>>> stateless do REST de maneira positiva. Sei que eles trazem ganhos de<br>
>>>>> performance muito grande na leitura de dados, mas não que mude a arquitetura<br>
>>>>> em sí. Vc pode dar algum exemplo?<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> [1] exceção de proxys que tentam colocar cache, ad's e bloquear o<br>
>>>>>> acesso, mas esse nao é o proxy que eu falo!<br>
>>>>>> inclusive isso me lembra que, a maior parte de quem usa proxys de<br>
>>>>>> cache, tipo o varnish, fazem algum IF para dropar o cache caso tenha alguma<br>
>>>>>> indicação de 'stateful' no header/api-key.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 2015-01-28 10:45 GMT-02:00 Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>>:<br>
>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> O REST mantém o conceito de HTTP stateless, ou seja, o server nunca<br>
>>>>>>>>> sabe quem é o cliente, então não tem nada guardado em memória, não tem<br>
>>>>>>>>> nenhuma persistência de estado dos seus dados em relação aos seus clientes.<br>
>>>>>>>>> Isso é uma grande vantagem, mas para poucos, porque o grande alívio que ele<br>
>>>>>>>>> trás é para os serviços web que transacionam simultaneamente com milhṍes de<br>
>>>>>>>>> clientes, poupando memória, processamento, e infra em geral para persistir<br>
>>>>>>>>> os dados.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Não apenas, há várias outras vantagens em se trabalhar com<br>
>>>>>>>> stateless.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> As vantagens que eu vejo no stateless estão todas relacionadas com<br>
>>>>>>> otimização de memória, não cache em cluster, não administração de sessão<br>
>>>>>>> etc.<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Para outros webservices, que transacionam com "poucos clientes"<br>
>>>>>>>>> pode ser utilizada "qualquer arquitetura" que não fará muita diferença, vai<br>
>>>>>>>>> custar pouco e os servidores vão aguentar do mesmo jeito. Qdo falo em qquer<br>
>>>>>>>>> arquitetura, pode até ser um "REST stateful", que na verdade não é REST na<br>
>>>>>>>>> acepção da palavra.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Qual seria um exemplo?<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Por exemplo uma aplicação web stateful que ofereça todos os métodos<br>
>>>>>>> que as partes necessitam em um webservice, como criação, update, leitura e<br>
>>>>>>> deleção, sem se preocupar com a semântica dos métodos HTTP sem se preocupar<br>
>>>>>>> em ser stateles. Em suma, uma aplicação web qquer que retorne xml, json ou<br>
>>>>>>> qquer coisa inclusive documentos.<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Em termos de penetração de mercado acho REST limitado, e pensando<br>
>>>>>>>>> em um "REST stateful" acho que uma boa abordagem é o Websocket. O Websocket<br>
>>>>>>>>> elimina um outro problema do HTTP que além de ser stateless, é o<br>
>>>>>>>>> sincronismo. O HTTP é blocante e o cliente fica pendurado esperando a<br>
>>>>>>>>> resposta, carregando o servidor web. Já o Websocket é assincrono e por isso<br>
>>>>>>>>> aceita milhões de requisições que não ficam penduradas.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> WebSocket funciona em cima de HTTP :p<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Funciona sobre HTTP mas não é uma premissa. O Websocket usa o HTTP<br>
>>>>>>> para fazer handshake e aproveita toda a infra do HTTP como as portas 80 e<br>
>>>>>>> 443, proxy etc, mas a idéia é futuramente mandar ele para outra porta e<br>
>>>>>>> deixar o protocolo independente. Ele funciona como se fosse tunelado, ou<br>
>>>>>>> seja, se vc estabelecer uma camada de transporte para ele, o resto já tá<br>
>>>>>>> pronto. E a RFC diz que futuramente vai ser feito.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>> WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP<br>
>>>>>>>> sobre WebSocket seja uma solução mais robusta.<br>
>>>>>>>><br>
>>>>>>>> E em muito tempo a única forma racional (efetiva, eficaz e<br>
>>>>>>>> eficiente) que encontrei para implementar sistemas com WebSocket é baseada<br>
>>>>>>>> em Schema/LD.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Faz sentido, pq o Websocket é um protocolo e REST é uma arquitetura.<br>
>>>>>>> AMQP começa a ser uma composição de MQ com Websocket e tal. Aí começa a se<br>
>>>>>>> montar uma arquitetura compondo várias tecnologias e protocolos.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Não estou dizendo que a arquitetura REST não é boa nem que não tem<br>
>>>>>>>>> utilidade, mas que é para poucos. HATEOAS me soa a mesma coisa, eu nunca<br>
>>>>>>>>> tinha ouvido falar, mas me lembrou WSDL, SOAP, etc.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Na verdade Rest é oposto a SOAP, que embora também suporte<br>
>>>>>>>> documentos e não apenas RPC, não tem as premissas de funcionar em WEB.<br>
>>>>>>>><br>
>>>>>>>> Mas, sim, para fazer RPC tunelado sobre HTTP, XMPP, SMTP eu diria<br>
>>>>>>>> que ainda hoje o padrão mais maduro é, sem dúvida, SOAP/WSDL. Certamente é o<br>
>>>>>>>> que torna o desenvolvimento de software mais fácil.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Eu já trabalhei em uma implementação de SOAP e WSDL em PERL. A<br>
>>>>>>> empresa consumia os nossos webservices e foi uma solução interessante, a<br>
>>>>>>> arquitetura era deles. Eu acho que a solução funcionava bem porque não eram<br>
>>>>>>> muitos requests, senão valeria a pena pensar em algo assíncrono.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Em 26 de janeiro de 2015 21:08, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>>>>>>>>> escreveu:<br>
>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus<br>
>>>>>>>>>> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>> escreveu:<br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> Eu uso o Catalyst::Controller::REST que implementa todo o “sexo<br>
>>>>>>>>>>> dos anjos” pra mim e vou ser feliz :D<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> Não falta pretenção para o Catalyst::Controller::REST<br>
>>>>>>>>>><br>
>>>>>>>>>> Quanto a ser feliz, bem, eu acredito que se conseguirmos construir<br>
>>>>>>>>>> uma infraestrutura de software e uma prova de conceito Rest em Perl, em cima<br>
>>>>>>>>>> do Catalyst, por exemplo, com View, Controller e Model requerendo interfaces<br>
>>>>>>>>>> Rest de classes Moose (incluindo DBIx::Class Result(set)), vamos ser mais<br>
>>>>>>>>>> que felizes.<br>
>>>>>>>>>><br>
>>>>>>>>>> Se tiver uma galera na comunidade Perl entendo o que é Rest eu já,<br>
>>>>>>>>>> pessoalmente, ficarei muito feliz demais da conta.<br>
>>>>>>>>>><br>
>>>>>>>>>> Que a galera Java, por exemplo, já está acordando para a vida.<br>
>>>>>>>>>><br>
>>>>>>>>>>> Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>>>>>>>>>>> escreveu:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem<br>
>>>>>>>>>>> feito, há um motivo pelo qual todo mundo quer Rest: REST É O ÚLTIMO BISCOITO<br>
>>>>>>>>>>> DO PACOTE! JSON-RPC funciona, mas não é Rest e por isso não tem todas as<br>
>>>>>>>>>>> vantagens sensacionais do Rest.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Em 26 de janeiro de 2015 14:54, Renato Santos<br>
>>>>>>>>>>> <<a href="mailto:renato.cron@gmail.com">renato.cron@gmail.com</a>> escreveu:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Eu posso me juntar, mas já digo que eu só faço API's REST, não<br>
>>>>>>>>>>>> RESTFul, e que nunca ouvi falar de HyperDocument e que linked-data pra mim<br>
>>>>>>>>>>>> tem que ser em RDF!<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> 2015-01-26 14:51 GMT-02:00 Lucas Mateus<br>
>>>>>>>>>>>> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>>:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>>>>>>>>>>>>> escreveu:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Caso na comunidade tenha gente disposta a se atualizar sobre<br>
>>>>>>>>>>>>> Restful (um conceito novo, lançado em 2000, e que se tornou a principal<br>
>>>>>>>>>>>>> vedete do desenvolvimento de software contemporâneo) e disposta a parar de<br>
>>>>>>>>>>>>> mentir para seus chefes e clientes de que está entregando restful quando<br>
>>>>>>>>>>>>> está na verdade entregando um tipo de RPC mais-que-porco, eu teria um imenso<br>
>>>>>>>>>>>>> prazer em integrar um grupo de estudo e de desenvolvimento com esse<br>
>>>>>>>>>>>>> objetivo.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Hahaha comunidade de mentirosos :D<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>>>>>> =end disclaimer<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> --<br>
>>>>>>>>>>>> Saravá,<br>
>>>>>>>>>>>> Renato CRON<br>
>>>>>>>>>>>> <a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>
>>>>>>>>>>>> @renato_cron<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>>>>> =end disclaimer<br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> --<br>
>>>>>>>>>>> Leonardo Ruoso<br>
>>>>>>>>>>> Journalist, Perl developer and business consultant<br>
>>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>>>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>>>   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>>> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>>> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>>>> =end disclaimer<br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>>>> =end disclaimer<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> --<br>
>>>>>>>>>> Leonardo Ruoso<br>
>>>>>>>>>> Journalist, Perl developer and business consultant<br>
>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>>>>>>>>>><br>
>>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>>> =end disclaimer<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> =begin disclaimer<br>
>>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>>> =end disclaimer<br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> --<br>
>>>>>>>> Leonardo Ruoso<br>
>>>>>>>> Journalist, Perl developer and business consultant<br>
>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>>>>>>>><br>
>>>>>>>> =begin disclaimer<br>
>>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>>> =end disclaimer<br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> =begin disclaimer<br>
>>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>>> =end disclaimer<br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Saravá,<br>
>>>>>> Renato CRON<br>
>>>>>> <a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>
>>>>>> @renato_cron<br>
>>>>>><br>
>>>>>> =begin disclaimer<br>
>>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>>> =end disclaimer<br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> =begin disclaimer<br>
>>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>>> =end disclaimer<br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Leonardo Ruoso<br>
>>>> Journalist, Perl developer and business consultant<br>
>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>>>><br>
>>>> =begin disclaimer<br>
>>>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>>>> =end disclaimer<br>
>>>><br>
>>><br>
>><br>
>><br>
>> =begin disclaimer<br>
>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> =end disclaimer<br>
>><br>
><br>
><br>
><br>
> --<br>
> "o animal satisfeito dorme". - Guimarães Rosa<br>
><br>
> =begin disclaimer<br>
>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
> =end disclaimer<br>
><br>
=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br></div>