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 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, 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> > =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
