> 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
