[SP-pm] Como fazer?

Blabos de Blebe blabos at gmail.com
Mon Oct 24 06:18:44 PDT 2011


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 <edencardim em gmail.com>:
>>>>>> "Rafael" == Rafael Silveira <design.silveira em gmail.com> 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: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>


More information about the SaoPaulo-pm mailing list