http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Evil_things_might_happen_when_using_PerlFreshRestart
2011/10/24 Eduardo Almeida <[email protected]> > mod_perl >> > > É uma forma de rodar o seu código diretamente no processo do apache. É >> mais rápido que o FastCGI (acho até que é o mais rápido, mas nao >> conferi) e tem uma boa gama de problemas. É uma das "gambiarras" mais >> usadas pra melhorar performace de CGI. É semelhante ao que o PHP faz. >> > > Blabos, poderia falar mais sobre "tem uma boa gama de problemas" ?!? > > Obrigado .. > > > > > Eduardo Almeida - Engenharia de Software > [email protected] - 27 3021-1530 / 27 9600-0395 > > WEB2 Solutions - Inovando, sempre! > -----Original Message----- From: Blabos de Blebe > Sent: Monday, October 24, 2011 11:18 AM > To: [email protected] > Subject: Re: [SP-pm] Como fazer? > > > Ok, vejamos se eu consigo complementar o que o Eden disse... > > Vou partir do princípio que você está querendo descobrir qual a > pergunta, porque era assim que eu estava quando fazia as suas > perguntas. > > Vou usar de licença poética, vulgo, dados incompletos ou exagerados em > algum ponto. > > Reset geral... > > HTTP > > Primeiramente, HTTP é um protocolo, ou seja é um acordo feito entre as > duas partes, cliente e servidor, sobre como conversar. É como se eu > chegasse pra alguém na rua e dissesse: > > _Oi, fala português? > _Sim, falo. > _Então vamos bater um papo. > ... > > Eu, pessoalmente acho o HTTP robusto demais pra ficar obsoleto em > breve, pois ele ainda é sub-sub-utilizado. Talvez um HTTP 1.2 ou 2.0. > > Você pode dar uma olhada em: > https://github.com/blabos/**Docs/wiki/Protocolo-HTTP<https://github.com/blabos/Docs/wiki/Protocolo-HTTP> > > Servidor Web > > Um servidor web (vou usar esse termo com licença poética) é uma > aplicação que ao subir, fica escutando em uma porta específica. Ao > receber uma requisição de um cliente, ele escolhe uma estratégia pra > tratá-la, e responde de acordo, no caso, de acordo com o que ele > quiser responder, mas é comum seguir algum padrão. > > CGI, cgi e CGI.pm > > CGI, Common Gateway Interface, é um padrão de interface. Entre quem? > Entre o servidor web e a sua aplicação. > > Se sua aplicação segue o padrão cgi, não importa em que linguagem, ela é um > cgi. > > Ex: > > #include <stdio.h> > > int main(void) { > printf("Content-Type: text/html\n\n"); > } > > Pronto, uma aplicação cgi em C. Faça o teste. > > CGI.pm é um framework em Perl que te fornece diversas facilidades para > trabalhar dentro do padrão CGI. As que eu mais gosto são a CGI::param > e a CGI::cookie. Dá pra brincar muito só com isso. > > > A principal característica do CGI é que toda vez que o cliente pedir > ao servidor para executar um cgi, ou seja a cada refresh do browser, o > servidor precisa fazer um fork, seguido de exec e isso é inerentemente > lento. Por quê? Dever de casa. > > http://www.cs.vu.nl/~ast/ > > > > FastCGI e FCGI > > O FastCGI é um novo padrão de conversa entre servidor e aplicação. > Basicamente ele diz que ao invés de abrir um novo processo, o servidor > deve manter um processo rodando e aproveitá-lo entre as requisições. > > É mais rápido que o CGI. > > > mod_perl > > É uma forma de rodar o seu código diretamente no processo do apache. É > mais rápido que o FastCGI (acho até que é o mais rápido, mas nao > conferi) e tem uma boa gama de problemas. É uma das "gambiarras" mais > usadas pra melhorar performace de CGI. É semelhante ao que o PHP faz. > > > Catalyst, Mojlicious e Dancer > > São frameworks para construção de aplicações MVC, cada um com suas > peculiaridades. Já implementam as interfaces padrão com o servidor, > deixando pra você se preocupar somente com a sua aplicação, que cada > um vai dar o seus pulos pra conversar com o servidor sem te importunar > muito com esses detalhes. > > Ou seja, não se preocupe com configurações e concentre-se na sua aplicação. > > > Cookie > > O Cookie é uma sacada genial, que possui seus problemas, mas permite > ao HTTP, que é um protocolo state-less, emular uma máquina de estados, > vulgo sessão. > > > Recapitulando: > > Host Cliente <-- ( TCP/IP ) --> Host Servidor > > Aplicação Cliente <--( HTTP ) --> Aplicação Servidor > > Servidor Web <--( CGI/FastCGI/PSGI/WSGI ) -> Aplicação Web > > Note as várias camadas. O Eden deu um ótimo curso sobre isso na FEI. > Se ele repetir em janeiro, eu recomendo. > > > ... > > Esses conceitos são super simples, mas fundamentais pra começar a > fazer as perguntas certas. O problema é que esses cursos web de banca > de jornal passam por cima e ensinam a trabalhar somente com um cenário > bem específico. > > Não fosse assim talvez os buzzwords soap, wsdl, webservice e muitos > outros poderiam ter sido simplesmente mais uma aplicação restfull... > > Qualquer dúvida, google, depois pergunta :) > > > []'s > > > 2011/10/24 Eden Cardim <[email protected]>: > >> "Rafael" == Rafael Silveira <[email protected]> writes: >>>>>>> >>>>>> >> Rafael> Boa noite galera, tentarei ser direto! >> Rafael> Tenho o código a seguir >> >> Rafael> package MyApp::HomeController; >> >> Rafael> use base qw{Controller}; >> >> Rafael> sub new { >> Rafael> } >> >> Rafael> sub index { >> Rafael> ... >> Rafael> } >> >> Rafael> 1; >> >> Rafael> Qual a melhor forma de criar um server http, para qndo eu >> Rafael> acessar localhost/Home/index do meu browser eu obter o >> Rafael> retorno do metodo index? >> >> Sendo direto, não dá pra explicar a melhor forma dentro de um email. É >> igual perguntar a melhor forma de implementar um sistema operacional. A >> sua pergunta é difícil e a resposta, por consequência, vai ser >> difícil. Mas, assumindo que uma forma "não-melhor" é tolerável, aqui >> vai: >> >> --8<---------------cut here---------------start------**------->8--- >> package MyApp; >> use warnings; >> use strict; >> use IO::Socket; >> use Net::hostent; # for OO version of gethostbyaddr >> >> my $PORT = 9000; >> >> sub run { >> my ($class) = @_; >> my $server = IO::Socket::INET->new( >> Proto => 'tcp', >> LocalPort => $PORT, >> Listen => SOMAXCONN, >> Reuse => 1 >> ); >> >> die "can't setup server" unless $server; >> >> printf STDERR "[Server $0 accepting clients]\n"; >> >> while ( my $client = $server->accept() ) { >> my $hostinfo = gethostbyaddr( $client->peeraddr ); >> printf STDERR "[Connect from %s]\n", >> $hostinfo ? $hostinfo->name : $client->peerhost; >> >> my ( $method, $req_uri, $http_ver ) = split ' ', scalar <$client>; >> my $c_method = $class->uri_to_method($req_**uri); >> print $client "$http_ver 200 OK\n"; >> print $client "Content-type: text/plain\n\n"; >> print $client MyApp::Controller->$c_method($**client); >> print $client "\n"; >> } >> } >> >> sub uri_to_method { >> my ( $class, $uri ) = @_; >> $uri =~ s{/+}{_}g; >> $uri .= 'index' if $uri eq '_'; >> return $uri; >> } >> >> package MyApp::Controller; >> use warnings; >> use strict; >> >> sub _index { 'Hi, you hit the index' } >> >> sub _foo { 'Whoa, you hit foo' } >> >> sub _bar { 'Hey there, you hit bar' } >> >> sub AUTOLOAD { 'not found' } >> >> package main; >> >> MyApp->run; >> --8<---------------cut here---------------end--------**------->8--- >> >> Coloca isso num arquivo e roda, depois abre http://localhost:9000 no >> browser. Isso é uma implementação porta e grosseira extraída de perldoc >> perlipc que basicamente faz 80% do que os servers como o apache, nginx, >> HTTP::Server, Starman fazem. A "melhor forma" você vai encontrar olhando >> pro source de cada uma dessas implementações. Os outros 20% você termina >> em alguns anos, até lá, o HTTP provavelmente já estará caminhando para a >> obsolescência. De qualquer forma, a especificação se encontra em >> http://www.w3.org/Protocols/**rfc2616/rfc2616.html<http://www.w3.org/Protocols/rfc2616/rfc2616.html>, >> boa sorte! >> >> Rafael> Desculpe de novo, essa "mesma" pergunta, só que dessa vez >> Rafael> quero exemplificar dessa forma! >> >> Rafael> Nao sei qual lib usar para o HTTP, talvez um CGI::Fast ou >> Rafael> qlqr outra lib! >> >> Porque você quer usar essas libs mas não quer usar as que já fazem algo >> mais próximo do que você quer? Onde é o seu critério de corte? E porque >> você está na dúvida se usa HTTP ou CGI, você realmente sabe o que eles >> fazem e a relação entre os dois? >> >> Rafael> Mas por gentileza, gostaria de saber dessa forma! >> >> Rafael> Como vocês sabem estou aprendendo perl, ja me deram as dicas >> Rafael> para aprender Catalyst, mas antes, gostaria de descobrir >> Rafael> como fazer isso! >> >> Rafael> Desde já agradeço! >> >> Repetindo, se você olhar no fonte do Catalyst, vai encontrar uma >> implementação similar e muito melhor do que essa colada acima. Mas pra >> você entender o fonte, precisa entender o que ele está se propondo a >> fazer. De novo, eu sugiro que você aprenda a implementar algo bem básico >> usando um framework, nem precisa ser o Catalyst, qualquer um serve pra >> isso. Depois você acompanha a execução dele passo a passo com o debugger >> ou até enchendo o código de print(), etc.. >> >> -- >> Eden Cardim >> Software Engineer >> http://bit.ly/edencardim >> http://twitter.com/#!/edenc >> +55 73 9986-3963 >> =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<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<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<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > > > =end disclaimer > -- Saravá, Renato CRON Santos http://www.renatocron.com/blog/ @renato_cron <http://twitter.com/#!/renato_cron>
=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
