[SP-pm] IPC / Data::Dumper

Wed Jul 27 11:40:15 PDT 2011

> 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 <rbsnkjmr em gmail.com>:
> 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 <blabos em gmail.com> 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 <rbsnkjmr em gmail.com>:
>> > 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: SaoPaulo-pm em 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 em 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 em 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 em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>