Pessoal, a conversa ficou meio maluca. No começo eu não deixei muito claro qual era o propósito, mas depois só não entendeu quem não quis.
Eu preciso compartilhar uma sessão de browser, só isso. E vai funcionar o cookie jar, pois me lembrei que já fiz testes compartilhando o arquivo de cookie do Firefox com o LWP. Como eu já expliquei, eu estava tentando resolver com IPC pq é algo que acho melhor do que persistir estruturas de dados/objetos em disco, mas tinha me esquecido que o LWP já trabalha nesse esquema. O IPC com certeza vai me servir para outras coisas, mas felizmente ou infelizmente não serviu para o LWP, pq o objeto é muito complexo. A primeira resposta do Stanislaw em modo Gambiarra ON ilustra muito bem essa passagem de objetos entre diferentes processos, e funciona com coisas simples. É inseguro, mas pode ser adequado para alguns processos específicos em ambiente controlado. E podem ficar despreocupado que a intenção não é sobrecarregar servidor de fornecedor nenhum, é só agilizar alguns processos. Agradeço as respostas, todas foram de grande valor. 2011/7/27 Renato Santos <[email protected]> > Esse negocio de IPC nem faz muito sentido, > e a parte de 'outro processo' rodar no CRON faz menos ainda.. > > E se vc estiver querendo paralelizar requests da uma olhada se você não > acabar fazendo um *DDOS* e tomando BAN do seu fornecedor > > 2011/7/27 Blabos de Blebe <[email protected]> > >> > Para cada transação vai abrir uma sessão? Não necessariamente. O HTTP é >> > atômico, e para otimizá-lo existe o reaproveitamento de sessão na camada >> de >> > aplicação para ser reaproveitado em diferentes transações. >> >> Cara, HTTP não é necessariamente atômico (depende do que você está >> falando que é atômico). Tem certeza que vc não está confundindo sessão >> com conexão? >> >> O que é uma transação pra vc? Não entendi esse termo. >> >> Como disse o Eden, o HTTP é stateless e o mecanismo de sessão é uma >> abstração que serve pra indicar ao servidor que várias requisições >> distintas, ou seja, não atômicas, pertencem a um mesmo contexto. >> >> Aliás o reaproveitamento de conexão é algo que só existe a partir do >> HTTP/1.1, ou seja, se o servidor falar HTTP/1.0, independente do que >> você faça, vc vai necessariamente abrir uma nova conexão para cada >> requisição. >> >> > No lado cliente precisa tudo ser controlado pelo mesmo processo? Não >> > necessariamente, vai da necessidade de cada transação. >> >> Não entendi. >> >> Até bem pouco tempo todos os browsers processavam várias 'transações' >> em um único processo. Qual o problema? >> >> > Não sei se faz mais sentido agora. Acho que ficou bizarro quando entrou >> o >> > IPC na história... :) >> >> Pra mim não tá fazendo sentido nenhum misturar IPC com cliente de web >> site. Ajude-me a te ajudar. >> >> Pelo que eu entendi vc precisa acessar um site de um fornecedor e >> interagir com ele. O normal é criar um user agent, submeter >> requisições e tratar as respostas. Nada de IPC, a menos que vc tenha >> algo muito específico. É isso? >> >> Dê uma olhada no link abaixo e vamos tentar sincronizar a conversa. >> Acho que estamos falando de coisas diferentes. >> https://github.com/blabos/Docs/wiki/Protocolo-HTTP >> >> >> >> 2011/7/27 Kojo <[email protected]>: >> > O que estou tentando resolver é justamente o compartilhamento de sessão >> > entre diferentes processos. >> > Vou explicar o cenário e dar um exemplo. >> > Cenário: >> > Tenho um fornecedor que disponibiliza o serviço via web site. >> > Exemplo: >> > Veja bem, é só um exemplo. Imagine uma livraria pela Internet, que >> compra, >> > vende, tem um chat, divulgação de notícias etc, e ele é o seu >> fornecedor. >> > Vc quer se conectar ao sistema dele e automaticamente, comprar, vender, >> > acompanhar o bate-papo, ver as notícias etc... >> > Para cada transação vai abrir uma sessão? Não necessariamente. O HTTP é >> > atômico, e para otimizá-lo existe o reaproveitamento de sessão na camada >> de >> > aplicação para ser reaproveitado em diferentes transações. >> > No lado cliente precisa tudo ser controlado pelo mesmo processo? Não >> > necessariamente, vai da necessidade de cada transação. >> > Não sei se faz mais sentido agora. Acho que ficou bizarro quando entrou >> o >> > IPC na história... :) >> > Obrigado pela indicação do livro, vou colocá-lo na lista. >> > >> > >> > >> > >> > Em 27 de julho de 2011 13:15, Blabos de Blebe <[email protected]> >> escreveu: >> >> >> >> Cara, >> >> >> >> Por que raios tem que ser a mesma sessão? >> >> >> >> Com as informações que você deu até aqui, o que vc quer fazer não faz >> >> o menor sentido. >> >> >> >> Me corrija se eu estiver errado: vc quer reaproveitar um mesmo user >> >> agent transacionando em uma mesma sessão só que em processos >> >> diferentes? Pra quê? >> >> >> >> Está me cheirando a confusão conceitual. Explique melhor qual o >> >> *problema* que vc está tentando resolver. >> >> >> >> Se você está tentando usar IPC eu imagino que você já leu o capítulo 14 >> do >> >> apue: >> >> >> >> >> http://www.amazon.com/Programming-Environment-Addison-Wesley-Professional-Computing/dp/0201563177 >> >> >> >> Partindo disso e sabendo como funciona o modelo de processo do UNIX, >> >> vc sabe que a menos que sua linguagem preferida possua um eval da >> >> vida, não dá pra executar código de um processo a partir de outro, >> >> certo? E que por isso IPC normalmente (ignore os exoterismos por >> >> enquanto) refere-se a troca de dados e soemtne dados, certo? >> >> >> >> Então, qual o problema que vc está tentando resolver? >> >> >> >> []'s >> >> >> >> 2011/7/27 Kojo <[email protected]>: >> >> > Comentários em linha: >> >> >> >> >> >> Porque você não simplesmente passa um nome de arquivo explícito pro >> >> >> cookie jar do LWP, daí qualquer LWP que você criar passando esse >> >> >> arquivo >> >> >> ai ter o mesmo conjunto de sessões. >> >> > >> >> > Kojo -> Vou testar isso. Se o LWP consegue manter tudo no cookie jar >> >> > vai >> >> > ser a melhor saída. >> >> > >> >> >> >> >> >> Apesar que nada disso deveria ser necessário, se você fizer um >> fork() >> >> >> no >> >> >> processo (que é o que o IPC::Lite faz por trás das cenas), o objeto >> LWP >> >> >> é copiado automaticamente pra você, com a sessão e tudo. Explica >> melhor >> >> >> o teu requisito, porque pelo que você falou até agora, não tem >> >> >> necessidade de usar o Data::Dumper. >> >> > >> >> > Kojo -> Eu pensei nessa possiblidade, mas veja só, um dos processos >> que >> >> > reaproveitaria o LWP via IPC é disparado via crontab. Para eu rodar >> esse >> >> > processo via fork a partir do processo que inicializa o LWP, eu teria >> >> > que >> >> > implementar um "crontab" na mão para rodar o processo filho nos >> horarios >> >> > determinados. Eu até procurei umas libs para isso, mas sujaria muito >> a >> >> > solução. >> >> > O Data::Dumper era só para serializar o LWP para passar via >> IPC::Lite, >> >> > que >> >> > não consegue passar objetos. >> >> > Vou testar o cookie jar hoje a noite, e posto o resultado... >> >> > >> >> >> >> >> >> -- >> >> >> Eden Cardim Need help with your Catalyst or DBIx::Class >> >> >> project? >> >> >> Code Monkey >> http://www.shadowcat.co.uk/catalyst/ >> >> >> Shadowcat Systems Ltd. Want a managed development or deployment >> >> >> platform? >> >> >> http://blog.edencardim.com/ >> >> >> http://www.shadowcat.co.uk/servers/ >> >> >> http://twitter.com/#!/edenc >> >> >> =begin disclaimer >> >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >> >> SaoPaulo-pm mailing list: [email protected] >> >> >> 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: [email protected] >> >> > 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: [email protected] >> >> 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: [email protected] >> > 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: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> > > > > -- > Renato Santos > http://www.renatocron.com/blog/ > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
