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