APR (Apache Portable Run-Time)
Tem toda relação com o
item
anterior
, em larga escala. É talvez a mais importante das novas
características do Apache 2.0. Nas versões
anteriores portabilidade era tratada internamente, feita
dentro de padrões, porém pelos programadores. Com o
2.0 a portabilidade será orientada via APR, não
será mais opção. O objetivo da APR é
prover uma interface em C para as funções
específicas dependentes de plataforma.
Tal características tem vantagens como o código
ficar mais bem arrumado e a manutenção ser
facilitada. Além disso, a essência, cada chamada
usa código nativo sempre que possível. Se você
esta no Windows, você tem um programa que é
nativamente escrito para Windows, com cara de Windows, com a
performance compatível a chamadas Windows. Assim como em
todas as outras plataforma. Isso proporciona um ganho
bastante grande de performance. Tal interface e conceito foi
feito pensado nas funções POSIX conhecidas por
nós, programadores C. Só que é específico
para as funcionalidades do Apache. Como percebido, facilita
de sobremaneira a portabilidade para outras plataformas.
Uma pergunta que pode surgir, é porque não usar
POSIX puro para fazer isso, em vez do APR? Usando APR da mais
flexibilidade para o desenvolvedor no sentido de POSIX ser
uma padronização geral, seguida por muitos, mas que
é um nivelamento por baixo de funções
básicas. Quase todas plataformas tem funções
não POSIX semelhantes que tem ganhos de performance ou
funcionam mais adequadamente para determinada
função, e como temos um foco bem definido,
performance, é importante esse tipo de
maleabilidade.
Podemos citar algumas coisas implementadas via APR como
funções básicas de I/O de arquivos, logs,
exclusão mútuas (semáforos), memória
compartilhada, gerenciamento de processos filhos, IO
assincrônico, entre outros.
APR/MPM oferecem dois importantes benefícios com
flexibilidade no tratamento de processos e
diferenciação de plataformas:
- O Apache pode suportar uma grande quantidade de SOs
mais limpo, manuseável e eficiente. Em particular, a
APR e a não necessidade de nivelar por baixo com o
POSIX possibilita isso tudo (portabilidade).
- Adequação maior as necessidades particulares
de cada site. Através da escolha da MPM você tem
as características mais adequadas para cada realidade,
pode-se escolher entre faixas de escalabilidade,
confiabilidade, flexibilidade, robustez, entre outras
características. Além de características de
servir diferentes domínios (virtual host) com
níveis de acesso a máquina Usuários/Grupos
diferenciados (escalabilidade/flexibilidade).
Novos filtros
O que são filtros? Para cada requisição o
Apache identifica o objeto de requisição, que pode
ser um documento no disco, a saída de um CGI, a
saída de um módulo como o de SSI (Server Side
Include). Não existe a habilidade nativa de se processar
a saída de um script CGI interpretando tags SSI e
devolvendo o resultado para o usuário. Podemos
utilizando de artifícios (patches) para fazer isso com o
servidor, mas é bastante custoso e não muito
prático. Através de filtros podemos redirecionar a
saída de uma dessas ações para outras,
encadeando-as.
No Apache 1.3 quando escrevemos um filtro, é bastante
normal querermos modificar dados que chegam a nós. Por
exemplo, hipoteticamente estamos escrevendo um filtro para
todas as páginas que são servidas por nós,
botarmos um rodapé flutuante dizendo que aquela
página pertence ao nosso provedor de serviços, que
gratuitamente cede espaço aos usuários. Isso é
bastante comum e acontece com vários provedores, como o
conhecido Geocities. No Brasil, vindo a cabeça agora,
temos o HPG, provedor de espaço que foi comprado pelo
IG. Em todas as páginas que ele fornece ele envia um
popup dele, com suas propagandas, independente da vontade do
usuário do serviço. É uma maneira dele
patrocinar suas operações e poder prestar esse tipo
de serviço gratuito. Em casos como estes o caminho mais
simples é escreve um módulo que intercepte toda
conexão e antes de enviar qualquer dado, insira o seu
dado no fluxo que vai para o usuário.
