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