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 ?
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