Apache™ Bloodhound 0.6 : Bootstrap handlers

Rumbo a la próxima liberación de la versión 0.6 de ​Apache™ Bloodhound en este artículo comienzo una serie con el objetivo de presentar las diferentes características que marcan pautas con respecto a las versiones precedentes . Explicaré brevemente su utilidad y funcionamiento. Estimo tener tiempo también para redactar algún que otro tutorial . Espero que me perdonen si no logro satisfacer todas las expectativas . Comprendan que todavía hay muchas cosas por hacer y estoy increíblemente ocupado . Tod@s l@s interesad@s en estos temas pueden mantenerse informados del desarrollo de la serie . Solo deben ​suscribirse mediante RSS .

Hasta el presente ​la arquitectura que me robó tantas noches de sueño ha probado satisfacer el 95% de los requisitos que se plantearon inicialmente . Para conocer los detalles , empezamos por el principio ...

¿Qué son los bootstrap handlers?

Una aplicación web consta de múltiples funcionalidades , secciones y opciones de navegaciones. Por lo tanto todo framework de desarrollo de aplicaciones web contiene un subsistema que se encarga de seleccionar el componente (e.g. clase) responsable por procesar las peticiones HTTP que se envían hacia el servidor. ​Trac y por consiguiente ​Apache™ Bloodhound no son la excepción . En las versiones anteriores (i.e. Bloodhound<0.6 ) el manejo de las peticiones web de ambos gestores de incidencias lo realizaban exactamente las mismas clases exactamente de la misma forma.

En pocas palabras a partir de la versión 0.6 de Apache™ Bloodhound el manejo de peticiones web varía un poco ... y para mejor :) . El siguiente diagrama muestra cómo es que todo esto se lleva a cabo.

El primer actor que interviene en el lado del servidor es siempre un servidor web e.g. ​Apache httpd , ​Nginx , ​tracd, ... en fin , cualquier servidor que sea capaz de correr sitios implementados con ​Python. Posteriormente , de ser necesario, se ubican los frontends (gateways) responsables de adaptar las tecnologías del servidor web (e.g. CGI, FastCGI, ...) al estándar WSGI . En todos los casos se llega a la función trac.web.main.dispatch_request , el punto de entrada del manejo de peticiones web de Trac . Hasta este punto Bloodhound solo introduce cambios menores relacionados con el middleware de autentificación de tracd ; nada en especial.

A partir de este punto aparecen las diferencias . El algoritmo de Trac funciona de la manera siguiente:

1. Trac determina la configuración de los directorios donde están los environments,
   estableciendo si se corren varios dentro de una misma carpeta o uno solo .
   
2. Trata de extraer del camino de la URL el nombre del environment al que va
   dirigido la petición e.g. si la URL fuera http://dominio.com/env/something/else
   entonces el camino de la URL sería /env/something/else y el primer componente
   seria el nombre del environment (env en el ejemplo).
   
   • En caso de no conseguirlo e.g. si la URL fuera http://dominio.com/
     entonces muestra un índice de los proyectos disponibles.
     
3. Se instancia el environment al que va dirigida la petición.
   
4. Se crea un objeto del tipo trac.web.api.Request
   
5. Se utiliza el resto del camino e.g. /something/else para determinar dentro
   de ese environment la instancia de la interfaz trac.web.api.IRequestHandler
   que es responsable de procesar la petición y dar
   una respuesta al cliente.
   

En la práctica los pasos (2) , (3) y (4) son un poco limitados . La razón por la cual Apache™ Bloodhound introduce los objetos llamados bootstrap handlers es exactamente poder implementar algoritmos personalizados para realizar estos pasos. Como consecuencia los pasos anteriores varían de la siguiente manera :

1. Bloodhound determina la configuración de los directorios donde están los environments,
   estableciendo si se corren varios dentro de una misma carpeta o uno solo .
   
2. En la variable WSGI trac.bootstrap_handler se busca una
   ​definición de entry point (e.g. package.module:object.attribute)
   con el módulo y la referencia al objeto bootstrap handler
   
   • si no se encuentra dicha instancia se utiliza trac.hooks.default_bootstrap_handler
     como valor predeterminado.
     
3. Se ejecuta el método open_environment() del objeto determinado en el paso anterior.
   Como resultado se obtiene :
   
   • El nombre del environment incluído en la variable trac.env_name
     del entorno WSGI
     
     • Nótese que el procedimiento puede ser completamente diferente a los pasos
       (2) y (3) de la secuencia anterior
       
   • El environment debidamente inicializado
     
     • La implementación predeterminada en trac.hooks.default_bootstrap_handler
       analiza el camino de la URL de manera similar a cómo se hace en Trac .
       La diferencia más notoria consiste en el hecho que las que comienzan con
       /products/ se asocian a ​environments de un producto
       e.g. http://dominio.com/env/products/P1/wiki/TitleIndex se procesaría
       en el contexto del environment del product P1 en el environment env
       mientras que la URL http://dominio.com/env/wiki/TitleIndex es procesada
       por el environment env (global) directamente.
       
4. Se ejecuta el método create_request para obtener un objeto
   del tipo trac.web.api.Request o equivalente
   
5. Se utiliza el resto del camino e.g. /something/else para determinar
   la instancia de la interfaz trac.web.api.IRequestHandler dentro
   de ese environment que es responsable de procesar la petición y dar
   una respuesta al cliente.
   

Variantes existentes de bootstrap handlers

El framework ​Routes , inspirado en ​Ruby on Rails , se ha convertido en el estándar para este tipo de enrutamiento de peticiones . En un proyecto que será publicado próximamente se están preparando unas variantes que permiten el uso de este framework para implementar bootstrap handlers para Apache™ Bloodhound. De especial interés resultan los casos en que se utiliza el encabezamiento HTTP Host para identificar los environments a partir del dominio al que va dirigida la petición e.g. http://dominio.com/wiki/TitleIndex para el environment global y http://P1.dominio.com/wiki/TitleIndex para el environment del producto P1 . Otro campo de aplicación es la integración con otros frameworks e.g. ​Pylons , ​Turbogears 2 , ...

Conclusiones

​Apache™ Bloodhound ofrece una versión mejorada del mecanismo que facilitaría tanto despliegues similares a los de Trac como otros basados en sub-dominios , más parecidos al dominio edgewall.org (i.e. babel.edgewall.org, genshi.edgewall.org, trac.edgewall.org) . Todo esto es posible gracias a ​la arquitectura multi-productos ; que ha probado satisfacer el 95% de los requisitos que se plantearon inicialmente para Apache™ Bloodhound .

Solo me queda invitar a tod@s l@s interesad@s en estos temas a ​suscribirse mediante RSS a este blog para estar al tanto de las mejoras que propone este gestor de incidencias .