TuxInfo 61 : Instalando Apache™ Bloodhound 0.7

Unos pocos días atrás se ​anunció el ​número 61 de la revista argentina de software libre ​TuxInfo. Este volúmen incluye mi más reciente artículo acerca de Apache™ Bloodhound titulado Instalando Apache™ Bloodhound 0.7. Estructurado en forma de tutorial explica paso a paso el proceso de instalación de la versión estable más reciente de este sistema de gestión de incidencias prestando atención a los dos motores de bases de datos recomendados: SQLite y PostgreSQL. En próximos espacios repasaré las particularidades del proceso para crear una instancia con MySQL. En mi tiempo libre también confeccionaré más tutoriales acerca de otros temas muy interesantes relacionados con las posibilidades que ofrece el ​soporte multi-producto incluído por primera vez en esta versión, así como las mejoras en la navegación del sitio y las poderosas herramientas que añaden varios plugins que estamos desarrollando en estos momentos. Si estos temas son de su interés le invito a ​suscribirse a este blog y a seguir los desarrollos en ​olemis @ Bitbucket y ​olemis @ Github.

En los últimos dos días se reportan unas 515 descargas de la revista. Todos quieren saber acerca de las noticias más recientes del software libre. No se pierda esta oportunidad de estar actualizado.

​Descarga gratuita de TuxInfo 61

Tengo el inmenso placer de compartir el espacio de la revista con otros colegas que han escrito los siguientes artículos:

• Instalando Apache™ Bloodhound 0.7
  
• DEB Libre – Tus paquetes DEB en un solo lugar
  
• GNU/Linux no es gratuito, es libre
  
• Falcon Pro… y sus trucos
  
• Instalando Google Play en una Coby Kyros
  
• Elementary OS – un GNU/Linux sencillo y elegante
  
• ... y una revisión de una ultrabook Dell XP13 con GNU/Linux.
  

También se comentan noticias como :

• Google y Motorola lanzaron oficialmente el Moto X, el primer smartphone de bandera Google directo.
  
• Debian cumplió 20 años de vida
  
• Ubuntu volvió a apostar por Firefox como navegador preinstalado
  
• Jean-Baptiste Quéru, el máximo responsable de Android Open Source dejó su cargo.
  

Apache™ Bloodhound 0.7 listo para descarga

Después de una votación inicial en la lista de discusión ​dev@bloodhound.apache.org los ​miembros del IPMC han ratificado la decisión de liberar la ​versión 0.7 del sistema de gestión de incidencias ​Apache™ Bloodhound . El ​anuncio oficial deja constancia de los siguientes votos

Matevž Bradač	binding	+1
Andrej Golcov	binding	+1
Anze Staric	binding	+1
Jure Zitnik	binding	+1
Olemis Lang	non-binding	+1
Gary Martin	binding	+1

Una recomendación importante para los despliegues existentes es actualizar el plugin ​ThemeEnginePlugin a la ​versión 2.2.1 o ​superior. Para los usuarios de la versión 0.6.0 es muy importante actualizarse a esta nueva versión, pues se han eliminado varios errores importantes. Algunos de ellos están relacionados con fallos detectados al configurar las notificaciones.

Ahora bien .... ¿qué es lo que incluye la versión 0.7?

Productos

Para instalar varios proyectos en Trac es necesario crear varios entornos de administración en carpetas separadas en el sistema de archivos y desplegar varias bases de datos independientes. Los productos de Apache™ Bloodhound permiten lograr resultados similares usando el mismo entorno de administración y compartiendo la base de datos. Cada producto permite asignar permisos para los usuarios y configuraciones de forma independiente.

Hace unas pocas semanas se publicó el sitio ​http://blood-hound.net . El despliegue todavía está en proceso de mejora, pero ya muestra resultados muy alentadores. En primer lugar este caso demuestra que es posible publicar varios productos en varios sub-dominios pero con todos los datos almacenados en una misma base de datos. En este caso cada sub-dominio (i.e. producto) está dedicado a desarrollar un plugin o grupo de paquetes con un fin específico. Se logra así una mayor flexibilidad pues cada uno funciona de forma relativamente independiente pero al mismo tiempo se pueden compartir recursos. Por ejemplo, se puede conectar un mismo repositorio a varios productos. Los usuarios y sus sesiones también son globales. El sistema también facilita mecanismos de búsqueda que ofrecen resultados en múltiples productos.

Todo esto tiene un gran número de implicaciones que trataré de ir explicando poco a poco en este blog.

Lo que se viene …

Antes de finalizar le dedicaré unas líneas a explicar en qué estamos trabajando en este momento con vistas a la próxima versión .

Las versiones futuras se verán beneficiadas por las mejoras que se vienen realizando en la infraestructura de pruebas. La idea fundamental es poder ejecutar la suite de pruebas bajo diferentes configuraciones. Como consecuencia se espera mejorar a corto plazo el soporte para otros sistema de bases de datos e.g. MySQL y otros servidores web e.g. nginx. Esto también permitirá detectar rápidamente los fallos que se puedan introducir al hacer cambios y ajustes, evitando así recurrir en los mismos problemas ya detectados.

Plugins desarrollados en blood-hound.net

Uno de los objetivos a corto plazo consiste en mejorar la compatibilidad de los plugins para RPC y autentificación OpenId. Se trabaja también en una solución generíca de visualización y análisis de datos. Todo esto será presentado próximamente en este blog. No dude en ​suscribirse mediante RSS si está interesado en seguir de cerca el desarrollo de Bloodhound y su comunidad.

Conclusiones

Es preciso mencionar que hay dos demos online : el primero desplegado en ​https://bh-demo1.apache.org con la versión más reciente en el repositorio (i.e. nightly build) y el segundo ​https://bh-demo2.apache.org con la última versión estable. Si siente curiosidad Usted puede utilizarlos para familiarizarse con Bloodhound. No hace falta ni registrarse ni tener un usuario. Si después está interesado le invito a ​descargar Apache™ Bloodhound 0.7 , a que lea los próximos números de la revista ​TuxInfo y queden a la espera de una nueva versión con muchas nuevas herramientas. Como siempre , espero que las mejoras sean de su agrado . No dude en comentar acerca de estas propuestas o sugerir mejoras . Todo es posible ... simelo pide .

SAP propone Apache™ Olingo para Apache™ Incubator

Recientemente se ha confeccionado ​la propuesta del proyecto Apache Olingo para dar continuidad a la implementación en Java de la ​versión 2.0 de ​OData hecha por ​SAP. Anteriormente la librería era desarrollada en ​su sitio de Github. Los objetivos consisten en actualizar el soporte para las versiones ​3.0 y ​4.0 del estándar. La propuesta inicial de integrantes consiste en empleados de SAP. Es por esto que la diversidad es uno de los temas fundamentales a considerar con vistas a la graduación del proyecto. Todo esto coincide en el tiempo con un desarrollo similar que llevo a cabo para ​Apache™ Bloodhound. Sin embargo, en los planes iniciales de Apache Olingo no se considera el desarrollo de una librería para Python.

Acerca de Apache™ Incubator

Es posible contabilizar más de 100 proyectos en el ecosistema de la ​Apache Software Foundation. ​Apache™ Incubator es el punto de partida en el camino a convertirse en un proyecto oficial de la fundación.

Knockout.js ... lo que Usted no vió

Le dediqué un tiempo a conocer más acerca del patrón ​MVVM . Me agrada, así que se suma a la lista de tecnologías relacionadas con Microsoft que realmente recomiendo. Este es un enfoque propuesto por la compañía que consiste, según sus propios autores, en una especialización del enfoque ​Modelo Vista Controlador para tecnologías como Windows Presentation Foundation y Silverlight. En la ingeniería de software este tipo de soluciones resulta muy útil para construir interfaces de usuario. Su ámbito de aplicación se ha extendido también al ​framework ZK (del cual tengo muy buenas referencias) y a HTML5. Incluso existe ​Google mdv, una variante relacionada con estos temas. En mi caso particular puse mi atención en la implementación para Javascript conocida como ​KnockuotJs. En esta ocasión no pretendo comentarles las peculiaridades de su uso . Para esto les recomiendo leer ​este artículo y la ​documentación de KnockoutJs. Más bien pretendo comentarles algunos detalles que me llamaron la atención al probar los ​tutoriales.

Dependencias y <select />

Al terminar con el primer tutorial debe quedarnos como resultado un modelo más o menos como el que se muestra a continuación.

// This is a simple *viewmodel* - JavaScript that defines the data and behavior of your UI
function AppViewModel() {
    this.firstName = ko.observable("Bert");
    this.lastName = ko.observable("Bertington");

    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();    
    }, this);

    this.capitalizeLastName = function() {
        var currentVal = this.lastName();        // Read the current value
        this.lastName(currentVal.toUpperCase()); // Write back a modified value
    };
}

// Activates knockout.js
ko.applyBindings(new AppViewModel());

A continuación se muestra la vista relacionada después de añadir un elemento <select /> conectado con el atributo lastName del modelo.

<!-- This is a *view* - HTML markup that defines the appearance of your UI -->

<p>First name: <strong data-bind="text: firstName">todo</strong></p>
<p>Last name: <strong data-bind="text: lastName">todo</strong></p>
<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
<p>Full name: <strong data-bind="text: fullName"></strong></p>
<button data-bind="click: capitalizeLastName">Go caps</button>

<p>Last name: 
  <select data-bind="value: lastName" >
      <option value="x">Pérez</option>
      <option>Suárez</option>
      <option value="z">García</option>
      <option>Bertington</option>
      <option>BERTINGTON</option>
  </select>
</p>

En este punto me resultó muy interesante que la librería preserva automáticamente la consistencia del modelo teniendo en cuenta los bindings. Esta es la razón por la cual el botón Go caps solo funciona cuando el apellido es Bertington . La razón es que el binding con el combobox limita el número de valores que se le puede asignar al atributo del modelo. En el ejemplo el valor mencionado es el único que tiene también una opción con las letras mayúsculas.

Las listas y <select /> ... otra vez …

Pasando la página (literalmente ;) llegamos al segundo ejemplo que trata sobre los bindings para listas y colecciones de objetos. Lo que se muestra es impresionante y se completa cada paso satisfactoriamente; pero ... hay (al menos) un detalle muy sutil que se escapa. Utilizando ​Firebug, ​DragonFly o una herramienta similar es posible constatar que el atributo value de los elementos <option /> utilizados para escoger el menú siempre está asignado a una cadena vacía (al menos en las versiones de Opera, Firefox y Google Chrome que utilicé para probar ...). Con el fin de enviar los datos hacia el servidor es posible que sea útil asignar ciertos identificadores. Para lograr ese objetivo en la versión final es posible añadir en el model el atributo mealId

// Class to represent a row in the seat reservations grid
function SeatReservation(name, initialMeal) {
    var self = this;
    self.name = name;
    self.meal = ko.observable(initialMeal);

    self.formattedPrice = ko.computed(function() {
        var price = self.meal().price;
        return price ? "$" + price.toFixed(2) : "None";        
    });
}

// Overall viewmodel for this screen, along with initial state
function ReservationsViewModel() {
    var self = this;

    // Non-editable catalog data - would come from the server
    self.availableMeals = [
        { mealId: "s", mealName: "Standard (sandwich)", price: 0 },
        { mealId: "p", mealName: "Premium (lobster)", price: 34.95 },
        { mealId: "u", mealName: "Ultimate (whole zebra)", price: 290 }
    ];    

    // Editable data
    self.seats = ko.observableArray([
        new SeatReservation("Steve", self.availableMeals[0]),
        new SeatReservation("Bert", self.availableMeals[0])
    ]);

    self.addSeat = function() {
        self.seats.push(new SeatReservation("", self.availableMeals[0]));
    }

    self.removeSeat = function(seat) { self.seats.remove(seat) }

    self.totalSurcharge = ko.computed(function() {
       var total = 0;
       for (var i = 0; i < self.seats().length; i++)
           total += self.seats()[i].meal().price;
       return total;
    });
}

ko.applyBindings(new ReservationsViewModel());

Después es necesario utilizar el binding optionsValue en la vista como se muestra a continuación:

<h2>Your seat reservations</h2>

<button data-bind="click: addSeat">Reserve another seat</button>

<table>
    <thead><tr>
        <th>Passenger name</th><th>Meal</th><th>Surcharge</th><th></th>
    </tr></thead>
    <!-- Todo: Generate table body -->
    <tbody data-bind="foreach: seats">
        <tr>
            <td><input data-bind="value: name" /></td>
            <td><select data-bind="options: $root.availableMeals, value: meal, optionsText: 'mealName', optionsValue: 'mealId'"></select></td>
            <td data-bind="text: formattedPrice"></td>
            <td><a href="#" data-bind="click: $root.removeSeat">Remove</a></td>
        </tr>
    </tbody>
</table>

<h3 data-bind="visible: totalSurcharge() > 0">
    Total surcharge: $<span data-bind="text: totalSurcharge().toFixed(2)"></span>
</h3>

Al aplicar estos cambios se logra generar unos elementos como los siguientes:

<select data-bind="options: $root.availableMeals, value: meal, optionsText: 'mealName', optionsValue: 'mealId'">
  <option value="s">Standard (sandwich)</option>
  <option value="p">Premium (lobster)</option>
  <option value="u">Ultimate (whole zebra)</option>
</select>

¡Urra! ... pero no todo es color de rosa. Como resultado la columna Surcharge deja de actualizarse . Por consiguiente no se muestra el sub-total que se calcula en el último paso. Sin embargo el comando Remove introducido en esa misma etapa sí sigue funcionando. Esto me hace pensar que haya algún problema al calcular alguno de los diferentes tipos de bindings involucrados.

Quizás existe una forma de hacer que vuelvan a funcionar las actualizaciones, pero hasta este momento no la he encontrado. Tampoco he tenido mucho tiempo para profundizar en el tema.

Conclusiones

​KnockuotJs es una librería excelente. Sinceramente preferiría que algunos detalles de los bindings fueran más parecidos al estilo de Genshi. De todas maneras los própositos son diferentes; quizás ni siquiera sea apropiado o posible realizarlo.

Me da la impresión de que no voy a poder dejar de utilizarlo después que lo pruebe en alguna aplicación. La recomiendo. Le invito a ​suscribirse a este blog mediante RSS si desea conocer si descubro algo más en el resto de los tutoriales . En próximos artículos comentaré cómo utilizar esta solución para enriquecer la experiencia de usuario de sus aplicaciones. A pesar de estas pifias los resultados son impresionantes.

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 .

Brython migra de Google Code hacia Bitbucket

Este artículo es fundamentalmente para informarles a los seguidores de este blog que el desarrollo de Brython se ha migrado desde Google Code (i.e. svn) hacia Bitbucket (hg + git) . Pero bueno ... ¿qué es Brython?

​Brython está diseñado para remplazar a Javascript como lenguaje de scripts en el lado del cliente . Para nadie es un secreto las límitaciones de este lenguaje que desde mucho tiempo ya domina en el ámbito de los lenguajes de script para los navegadores web . Este es el bloque fundamental para confeccionar la gran mayoría de las páginas web dinámicas. Sin este tipo de lenguajes la Internet sería ... bueno , como al principio . Esto quiere decir no tan divertida y útil como es ahora sino más bien orientada a un grupo reducido de personas con aplicaciones prácticas limitadas . Nada de mapas , ni de chat web , ni de hojas de cálculo , ni ...

Desde un punto de vista un poco más técnico Brython es una implementación de Python 3 adaptado al entorno HTML 5 . En consecuencia ofrece una interface a los objetos y eventos del DOM .

La ​galería muestra unos cuántos ejemplos , desde la creación de un documento simple hasta funcionalidades más complejas incluyendo drag-and-drop y navegación 3D .

A continuación les muestro el código completo de una página ...

<!doctype html>
<html>
<head>
<meta name="description" content="Brython">
<meta name="keywords" content="Python,Brython">
<meta name="author" content="Pierre Quentel">
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<script src="brython.js"></script>
<title>Brython</title>
<link rel="stylesheet" href="brython.css">
</head>
<body onload="brython()">
<center>
<table id="banner" cellpadding=0 cellspacing=0>
<tr>
<td><a class="banner" href="index.html">Home</a></td>
<td><a class="banner" href="tests/console_en.html">Console</a></td>
<td><a class="banner" href="gallery/gallery_en.html">Gallery</a></td>
<td><a class="banner" href="doc/en/index.html">Documentation</a>
<td><a class="banner" href="https://bitbucket.org/olemis/brython/downloads" target="_blank">Download</a></td>
<td><a class="banner" href="https://bitbucket.org/olemis/brython/src" target="_blank">Development</a></td>
<td><a class="banner" href="groups_en.html" target="_blank">Groups</a></td>
</tr>
</table>
</center>
<div style="text-align:center">
<img src="brython.png"></img><br><b>browser python</b>
</div>

<script type="text/python">
import time
import math
import datetime

sin,cos = math.sin,math.cos
width,height = 250,250 # canvas dimensions
ray = 100 # clock ray

def needle(angle,r1,r2,color="#000000"):
    # draw a needle at specified angle in specified color
    # r1 and r2 are percentages of clock ray
    x1 = width/2-ray*cos(angle)*r1
    y1 = height/2-ray*sin(angle)*r1
    x2 = width/2+ray*cos(angle)*r2
    y2 = height/2+ray*sin(angle)*r2
    ctx.beginPath()
    ctx.strokeStyle = color
    ctx.moveTo(x1,y1)
    ctx.lineTo(x2,y2)
    ctx.stroke()

def set_clock():
    # erase clock
    ctx.beginPath()
    ctx.fillStyle = "#FFF"
    ctx.arc(width/2,height/2,ray*0.89,0,2*math.pi)
    ctx.fill()
    
    # redraw hours
    show_hours()

    # print day
    now = datetime.datetime.now()
    day = now.day
    ctx.font = "bold 14px Arial"
    ctx.textAlign = "center"
    ctx.textBaseline = "middle"
    ctx.fillStyle="#FFF"
    ctx.fillText(day,width*0.7,height*0.5)

    # draw needles for hour, minute, seconds    
    ctx.lineWidth = 3
    hour = now.hour%12 + now.minute/60
    angle = hour*2*math.pi/12 - math.pi/2
    needle(angle,0.05,0.5)
    minute = now.minute
    angle = minute*2*math.pi/60 - math.pi/2
    needle(angle,0.05,0.85)
    ctx.lineWidth = 1
    second = now.second+now.microsecond/1000000
    angle = second*2*math.pi/60 - math.pi/2
    needle(angle,0.05,0.85,"#FF0000") # in red
    
def show_hours():
    ctx.beginPath()
    ctx.arc(width/2,height/2,ray*0.05,0,2*math.pi)
    ctx.fillStyle = "#000"
    ctx.fill()
    for i in range(1,13):
        angle = i*math.pi/6-math.pi/2
        x3 = width/2+ray*cos(angle)*0.75
        y3 = height/2+ray*sin(angle)*0.75
        ctx.font = "20px Arial"
        ctx.textAlign = "center"
        ctx.textBaseline = "middle"
        ctx.fillText(i,x3,y3)
    # cell for day
    ctx.fillStyle = "#000"
    ctx.fillRect(width*0.65,height*0.47,width*0.1,height*0.06)

canvas = doc["clock"]
# draw clock border
if hasattr(canvas,'getContext'):
    ctx = canvas.getContext("2d")
    ctx.beginPath()
    ctx.lineWidth = 10
    ctx.arc(width/2,height/2,ray,0,2*math.pi)
    ctx.stroke()
    
    for i in range(60):
        ctx.lineWidth = 1
        if i%5 == 0:
            ctx.lineWidth = 3
        angle = i*2*math.pi/60 - math.pi/3
        x1 = width/2+ray*cos(angle)
        y1 = height/2+ray*sin(angle)
        x2 = width/2+ray*cos(angle)*0.9
        y2 = height/2+ray*sin(angle)*0.9
        ctx.beginPath()
        ctx.moveTo(x1,y1)
        ctx.lineTo(x2,y2)
        ctx.stroke()
    time.set_interval(set_clock,100)
    show_hours()
else:
    doc['navig_zone'].html = "On Internet Explorer 9 or more, use a Standard rendering engine"
</script>

<p>
<div style="text-align:center;padding-left:15%;padding-right:15%;">
Without a doubt, you've seen a clock like this in demos of HTML5
<p><canvas width="250" height="250" id="clock">
<i>sorry, Brython can't make the demo work on your browser ; 
<br>check if Javascript is turned on
<br><div id="navig_zone"></div></i>
</canvas>
<p>
However, right click and view the source of this page...
<p>It is not Javascript code! Intead, you will find Python code
in a script of type "text/python"
<p>Brython is designed to replace Javascript as the scripting 
language for the Web. As such, it is a Python 3 implementation 
(you can take it for a test drive through a web 
<a href="/tests/console_en.html">console</a>), adapted to
the HTML5 environment, that is to say with an interface to
the DOM objects and events
<p>The <a href="gallery/gallery_en.html">gallery</a> highlights a few 
of the possibilities, from creating simple document elements 
to drag and drop and 3D navigation
</div>
</body>
</html>

... nada de Javascript \o/ .

¿Qué que es lo que hace? Solo use su navegador web preferido y consulte ​esta página para ver el ejemplo en acción .

¿Por qué la migración hacia Bitbucket? Bueno ... quizás ​este artículo les proporcione las respuestas . Es sobre Github pero no hay nada más parecido a ese modelo que Bitbucket, con la ventaja de poder tener a git y mercurial en un solo lugar. Google Code se queda un poco atrás .

Por el momento existen dos repositorios

• El repositorio oficial ​olemis/brython @ bitbucket (mercurial) creado con ​hgsubversion
• Un mirror ​olemis/brython-git @ bitbucket creado con git-svn y que se mantendrá sincronizado usando ​hg-git

Esperamos que este cambio sea beneficioso para la comunidad ya que todos podrán aportar al proyecto con mayor facilidad. Sus contribuciones serán bienvenidas ... especialmente simelo piden .

Apache™ Bloodhound : Progreso del soporte multi-producto

En artículos anteriores les había mencionado que una de las líneas de trabajo más prioritarias para las próximas versiones de Apache™ Bloodhound es la arquitectura multi-productos . A continuación les presento una línea de tiempo que ilustra el progreso que se va haciendo en esta dirección.

Espero que sigan el desarrollo de esta funcionalidad y que les sirva este gráfico para estimar cuando estaría listo el soporte multi-producto para Apache™ Bloodhound .

Apache Bloodhound 0.4.0 listo para descarga

Después de una votación inicial en la lista de difusión ​bloodhound-dev@incubator.apache.org los ​miembros del IPMC han ratificado la decisión de liberar la ​versión 0.4.0 del sistema de gestión de incidencias ​Apache™ Bloodhound . El ​anuncio oficial deja constancia de la aprobación de los siguientes miembros

Branko Čibej	mentor	+1
Greg Stein	mentor	+1
Christian Grobmeier		+1

Una recomendación importante para los despliegues existentes es actualizar el plugin ​ThemeEnginePlugin a la ​versión 2.1.3 o ​superior.

Ahora bien .... ¿qué es lo que incluye la versión 0.4.0?

Edición de tickets in-situ

Como es de esperar esta versión trae nuevas funcionalidades . En primer lugar la interfaz de los tickets se transforma cuando Javascript está habilitado en el navegador de los usuarios. En estos casos , la modificación de sus atributos se realiza a través de un formulario in-situ . Si el cliente no habilita la ejecución de scripts entonces se sigue utilizando la misma sección Modificar ticket que ofrecían las versiones precedentes .

Imagen de marca

Las páginas wiki de la guía de usuario incluídas durante la instalación (e.g. TracStandalone, TracWorkflow, ...) han sido renombradas . Ahora comienzan con el prefijo Guide/ (e.g. Guide/Standalone, Guide/Workflow, ...) . También se han modificado ligeramente los textos de los mensajes de error y algunas partes de las páginas del sitio (e.g. el pie de página) con el fin de facilitar la conformación de una imagen de marca personalizada . Esto es posible mediante la configuración de las opciones application_full , application_short, footer_left_postfix, footer_left_prefix, footer_right en la sección labels del fichero de configuración trac.ini. La siguiente figura ilustra cómo funcionan estas opciones .

Creación rápida de tickets

Hace unas semanas la revista ​TuxInfo publicó su ​número 54 conmemorando sus cinco años de publicación ininterrumpida ( ¡ Felicidades ! ) . En uno de los artículos abordé la solución inicial para especificar la descripción en el formulario de creación rápida de tickets. Ya es posible hacer este tipo de cosas en la versión 0.4.0 , aunque la forma definitiva es un poco diferente a la que expliqué en aquel momento. Además se ofrece la posibilidad de configurar los campos de los tickets que se mostrarán en el formulario, así como el orden en que aparecerán .

Lo que se viene …

Antes de finalizar le dedicaré unas líneas a explicar en qué estamos trabajando en este momento con vistas a la próxima versión .

En primer lugar , es una prioridad completar la arquitectura multi-producto . Me encuentro trabajando actualmente con ​Jure Zitnik en la rama ​bep_0003_multiproduct con vistas a tenerla lista para finales de febrero o principios de marzo , a más tardar (<= suelo ser así de optimista, sí ...) . Hay grandes expectativas alrededor de este tema , ya que es una de las debilidades que siempre se le señala a Trac y por consecuencia Bloodhound .

Como consecuencia de la reciente publicación de las versiones ​1.0.1 y ​1.1.1 de Trac . Muy próximamente se debe decidir cuál de ellas será distribuida con Bloodhound en el futuro inmediato . Por otra parte ​Ryan J. Ollos junto con Steffen Hoffmann preparan otras mejoras en el plugin ​AccountManagerPlugin , una pieza escencial en el funcionamiento de Bloodhound . ​Matevž Bradac y ​Peter Koželj trabajan en mejoras a la interfaz de usuario , especialmente orientadas a que se adapte a las diferentes resoluciones de pantalla (i.e. responsive layout) .

Una de las adiciones más prometedoras en la versión 0.4.0 es la búsqueda avanzada . La misma se desarrolla en paralelo y por el momento se ofrece como una extensión opcional . Aunque es funcional , todavía es una versión inicial . ​Andrej Golcov se encuentra mejorando y añadiendo otros aspectos . Sin embargo, no me detendré a ofrecer muchos más detalles porque este será el asunto que trataré en un artículo que publicaré próximamente .

Pronto habrán dos demos online : uno con la última versión estable y otro con la versión más reciente en el repositorio (i.e. HEAD) . Si está interesado le invito a ​descargar Apache™ Bloodhound 0.4.0 (incubating) , a que lea el próximo número de la revista ​TuxInfo y queden a la espera de una nueva versión con muchas nuevas herramientas . Como siempre , espero que las mejoras sean de su agrado . No dude en comentar acerca de estas propuestas o sugerir mejoras . Todo es posible ... simelo piden .

Tuxinfo 50: Apache™ Bloodhound un fork de Trac

Con mucho placer recibo la noticia de la publicación del ​número 50 de la revista ​TuxInfo. Realmente hay que destacar el esfuerzo que realiza todo el equipo y los colaboradores para mantener estos resultados . Se necesita mucha constancia y dedicación. Estoy hablando de medio centenar de ediciones que han logrado familiarizar a muchos usuarios con las características , ventajas y desventajas del uso del ​software libre . Este hecho coincide apróximadamente con el anuncio por parte de la ​Apache Software Fundation de la publicación oficial de la ​versión 0.1.0-rc1 de Bloodhound. Decidí escribir un poco acerca del tema para que todos pudieran conocer mejor esta herramienta de administración de proyectos. Este es el principio de una serie de artículos. Si desea estar al tanto de los detalles le invito a ​suscribirse mediante RSS

¿Qué es Bloodhound?

​Bloodhound es la propuesta de la ​Apache Software Foundation (ASF) como herramienta de administración de proyectos. Su desarrollo parte del archi-conocido projecto de código abierto ​Trac. Anteriormente ya he publicado en la revista algunos artículos sobre esta aplicación web y ya les había hecho algun ​comentario sobre Bloodhound. La idea central consiste en construir una variante mejorada de Trac orientada a facilitar su uso en entornos empresariales y soluciones llave en mano.
A continuación les muestro un esquema de la interfaz de usuario . Las líneas rojas solo resaltan las distintas partes y no aparecen en el diseño .

La explicación y el resto de la historia aparecen en el artículo . Si está interesado en saber, le invito a ​descargar TuxInfo 50 .

Estado actual del proyecto

El primer hito del proyecto ha sido la liberación de la ​versión 0.1.0-rc1 y la redacción de una simple ​guía de instalación que pueden utilizar los usuarios interesados en poner a punto una instancia del sistema. Esta acción fue avalada en primera instancia por una ​votación en la lista ​bloodhound-dev@incubator.apache.org . Los resultados se muestran a continuación

Mark Poole	+1	binding
Joachim Dreimann	+1	(non-binding)
Olemis Lang	+1	(non-binding)
Greg Stein	+1	binding
Ethan Jucovy	-1	(non-binding)
Hyrum Wright	+1	binding
Gary Martin	+1	binding

Posteriormente en una segunda votación realizada en la lista de discusión ​general@apache.org se ratificó la decisión al reunir los tres votos de los miembros del IPMC a favor de dar luz verde al anuncio oficial .

¿... y entonces ...?

Hasta ahora la participación en el proyecto ha representado una grata experiencia profesional que me ha permitido diseñar nuevas ​APIs dentro de Trac, expandir mis horizontes y conocer nuevas tecnologías. Destaco el caso de la librería ​Bootstrap de ​Twitter que ha sido utilizada para construir la interfaz de usuarios. ¡Impresionante! Espero poder tener tiempo para compartir mis descubrimientos con Usted en este blog, así que le invito a ​suscribirse mediante RSS si es que desea enterarse.

El futuro de Bloodhound en la ASF

En el futuro a corto y mediano plazo hay ciertos hitos que quisiera mencionar porque pueden impulsar el desarrollo y despertar el interés de otras personas dispuestas a participar y formar una comunidad. En primer lugar la instalación del sistema en el ​sitio de reporte de incidencias de la ASF permitirá añadir paulatinamente a Bloodhound como una alternativa al ​uso de JIRA. Además de este software comercial de la compañía ​Atlassian existen otras opciones basadas en aplicaciones de código abierto que son utilizadas por la fundación. Estas son Bugzilla y Scarab. Segun ​un mensaje enviado a bloodhound-dev todo parece indicar que ya comienza a haber interés en usar Bloodhound por parte del proyecto Apache^TM Steve.

Integración con Allura

La segunda gran oportunidad es la integración con el proyecto ​Apache Allura^TM . Aunque el nombre no les sea muy familiar estoy casi seguro que lo deben conocer. Este es el sistema que desarrolla ​Geek.net y que todos vemos en funcionamiento en el sitio ​Sourceforge.net. Su incorporación al proyecto ​Apache Incubator^TM es reciente. De hecho el sitio del proyecto ​Allura en Sourceforge.net todavía no ha sido migrado hacia los servidores de la fundación.
Esta aplicación web integra dentro de un mismo sitio un conjunto de herramientas de soporte al proceso de desarrollo y ofrece una plataforma unificada de administración. Todas estas razones la ubican como un competidor de ​GForge y otros sistemas similares , pero en este caso avalado por las tremendas credenciales que le otorga su uso en uno de los más grandes sitios de hospedaje de proyectos de código abierto.
Allura es un sistema extensible. Existe una ​API para integrar las herramientas y hacerlas trabajar de forma coordinada. En este contexto Bloodhound pudiera ser una de las aplicaciones que se pudiera integrar a esta plataforma. De hecho , ya había pensado acerca del tema desde el pasado año cuando escribía ​una nota de presentación de Bloodhound , en el momento que se concebía la idea. Por aquellos tiempos SF.net ofrecía instancias de Trac a los proyectos mediante su iniciativa ​Hosted Apps . Después de la increíble reacción inicial de la comunidad , este intento probó no ser sustentable a largo plazo. En el caso específico de Trac les puedo mencionar que el ​plugin para XML-RPC no era funcional. Recibí muchas peticiones de amigos que conocían que yo participaba en el desarrollo y mantenimiento del plugin. Se repetía una y otra vez que no lograban integrar la instancia de Trac desplegada en SF.net con el ​conector para Eclipse Mylyn . Solo pude orientarlos hasta llegar al punto en que no quedaba otro remedio que la intervención del proveedor de servicios; algo que no sucedió hasta donde tengo entendido. Al parecer no fue tarea fácil tampoco integrar las otras aplicaciones que se ofrecieron. Esto llegó hasta el punto crítico que motivó el ​anuncio del retiro del plan Hosted Apps.
Sin embargo, ahora que ambos proyectos coexisten en el marco del proceso de incubación de la ASF existe la posibilidad de que se concrete un conector de Bloodhound para Allura. La idea fue mencionada en un ​mensaje de Greg Stein a bloodhound-dev . Si prestan atención a la ​lista de proyectos en incubación es posible apreciar que Greg Stein es ​mentor en ambos casos.
Todos los detalles los podrá conocer Usted aquí en este blog. Aproveche la oportunidad de ​suscribirse mediante RSS para estar informado acerca de los acontecimientos . Si se decide a ​descargar e ​instalar Bloodhound , pues mejor. No dude en hacer cualquier tipo de pregunta . Simelo pide seguro que haré un poco de tiempo para responder sus inquietudes.

El SPDY de Google no es tan malo como el Internet Explorer (IMO)

Érase de una tarde de diciembre fría y nublada cuando debatía el archi-tema de Microsoft vs software libre en  una conversación con mis amigos  Román Fresneda,  Mauricio López y en especial  Leonardo Paneque , quien me preguntó

 Olemis Lang ¿qué opinión merece desde su punto de vista que  Google decidiese utilizar código propietario en su navegador y romper con la naturaleza abierta de la web? .

Esa conversación va a motivar que publique otros atículos próximamente así que, si está interesado en conocer otros temas polémicos sobre código abierto vs software privativo, le invito a  suscribirse mediante RSS.

El smartphone de la discordia en el Eden Virtual

De forma inmediata (ya que nadaba en un mar de ignorancia y desactualización acerca del tema) simplifiqué mi respuesta y empecé diciendo :

a ver  Paneque , sobre los navegadores ... si no quieres código propietario ahí : usa  Chromium (q es d hecho el q yo uso ;)

... y luego ...

‎ Paneque por si las moscas pásame la noticia esa del código propietario en  Chrome pq a lo mejor no estoy claro y puedo estar hablando d otra cosa ...

Después de leerme  el artículo de PC Mag en cuestión , siento que debo al menos abordar el tema. Para ello empiezo analizando el contenido del artículo. Luego reflexionaré acerca de algunos de los comentarios de las personas antes mencionadas.

Pues bien, con un título muy sugerente y acompañado de  unas diapositivas el artículo  Is Google Chrome the New IE6? trata de establecer un paralelo entre las prácticas que llevaron en su tiempo a Microsoft a establecerse como el líder absoluto e indiscutible en el sector de navegadores web; y las que recientemente aplica Google con el fin de fomentar el uso de los navegadores web bajo su influencia  Chromium Browser y  Google Chrome. Vale destacar que el primero es un producto basado en una comunidad de código abierto patrocinada por Google. Es allí donde surge la mayor parte de la innovación incorporada a este producto; que sirve de base para construir el segundo producto, que no es más que unaa versión personalizada, optimizada y absolutamante bajo el control de Google . De hecho en los metadatos del paquete de instalación para Ubuntu se puede constatar lo siguiente :

$ apt-cache show google-chrome-stable | grep Maintainer
Maintainer: Chrome Linux Team <chromium-dev@chromium.org>
$ apt-cache show chromium-browser | grep Maintainer
Maintainer: Fabien Tassin <fta@ubuntu.com>

... a buen entendedor con pocas palabras basta ;)

La hegemonía del gigante de Redmond antes mencionada se viene resquebrajando por varias razones entre las que se pueden mencionar el descuido de Microsoft, su estrategía de romper la web con el fin de imponer sus tecnologías, y el surgimiento de otros navegadores que apostaron por la innovación llegando al punto de revolucionar varios fundamentos de la red de redes.

Dos enfoques diametralmente distintos

En primer lugar , el artículo menciona características que introdujo el Internet Explorer 6 tan comunes hoy como pueden ser DHTML, CSS, y mecanismos de seguridad. Algunos de ellos se transformaron en estándares. Sin embargo no se menciona todas las otras tecnologías propietarias e incompatibilidades que perturbaban intencionalmente o no (pero sí sistemáticamente) la experiencia de navegación de los usuarios en la web con el fin de ratificar su dependencia y sacar a otros navegadores de la competencia . A continuación les menciono algunas ActiveX, Microsoft SharePoint, ... y ni me voy a desgastar en demostrar el gran número de incompatibiliades. Solo habra un libro de Javascript , CSS o HTML y muy pronto se dará cuenta de que la idea central de pronto se convierte en cómo lograr que funcione su sitio con Internet Explorer :$. Todo se fundamenta en que la compañía priorizaba sus ventas de software, y utiliza esta situación para obtener ventajas en la comercialización de sus productos, dígase Microsoft Windows, Microsoft Sharepoint, Microsoft Outlook , ... y otros ... Para redondear la idea, la estrategia consistía en que solo si se usa el Internet Explorer (en Windows) es posible acceder a las funcionalidades de sitios, intranets empresariales, y así sucesivamente.

Por otra parte la estrategia empresarial de Google se basa en servicios. Esto quiere decir que es de sumo interés en su caso que todo el mundo pueda acceder a dichos servicios de la forma más fácil que sea posible (si hay varias alternativas para llegar a un mismo fin , quizás mejor ;) y que la experiencia del usuario supere la de las ofertas de la competencia. Con el transcurso del tiempo esto ha redundado en su compromiso con las comunidades de código abierto que han construido un ecosistema orientado a facilitar el uso de sus servicios.

Supuestas ventajas

Pero todo no queda ahí . Google participa activamente en el esfuerzo de construir una web abierta para todos pero también tratando de innovar y transformar los pilares fundamentales para mejorar así su desempeño . Menciono algunos ejemplos para que esta idea no se quede en el aire : Jingle y Wave son las extensiones al protocolo XMPP que surgieron con los productos Google Talk y Google Wave; en el último caso se innovaron características significativas que pasaron a formar parte del conjunto de APIs que integran HTML 5, entre ellas el drag n' drop para subir y bajar ficheros ... en fin la lista sería extremadamente larga. Con el tiempo todo esto se fue estandarizando al punto en que la mayoría de los navegadores principales incorporan estos adelantos. Pero es oportuno destacar que en todos los casos antecedió un período en que Google , y en cierta medida la comunidad que les rodeaba, se encargó de hacer implementaciones y experimentar hasta llegar a un punto en que se estabilizaba el rendimiento de la solución. Al satisfacer los objetivos era propuesta como un estándar (en muchos casos un estándar de facto). Mientras esto ocurría muy frecuentemente sucedía que no era posible hacer las mismas cosas con otros navegadores que todavía no habían incorporado estas mejoras (... claro ... eran ¡ EXPERIMENTOS !) .

Con esta introducción llegamos al punto en que se empieza a hablar en el artículo de PCMag sobre el tema de la optimización de los servicios de Google mediante aplicaciones para Chrome, especialmente con el fin de permitir su uso offline. Bueno ... más de lo mismo hasta donde se puede ver. Todos los servicios de Google tienen una API y, si el navegador implementa partes de HTML 5 se pueden lograr resultados similares en otros navegadores. El hecho es simple : Google hizo una aplicación para Chrome como cualquier otra que Usted pueda hacer y que permite el uso offline de GMail . Vamos a hacerle la autopsia a este fenómeno (bisturí, por favor, pinzas ... :)

$ dpkg -L google-chrome-stable | grep crx$
/opt/google/chrome/default_apps/gmail.crx
/opt/google/chrome/default_apps/youtube.crx
/opt/google/chrome/default_apps/search.crx

$ apt-cache show google-chrome-stable | grep Version
Version: 16.0.912.63-r113337

Esto quiere decir que Google Chrome distribuye tres extensiones para GMail , Youtube y Google Search que, aparentemente, utilizan los mismos mecanismos de extensión que tienen a su disposición los desarrolladores. Por tanto el argumento de que en Chrome no hay aplicaciones para Yahoo! Mail, Hotmail , Blip.tv, Bing , ... se soluciona con la repuesta : Solo hay que hacerla. ¿Qué esperan? . El argumento de que les puede dar cierta ventaja a los productos de Google y que hay quienes pueda no gustarles y prefieran el sitio web tiene una respuesta simple ... son aplicaciones como otra cualquiera. Desinstale la que no le guste ... El argumento de que no hay aplicaciones similares para Firefox , Opera, Internet Explorer, Safari solo se explica por el hecho de que no hay una API , librería ... que permita el desarrollo de plugins para varios navegadores , y mucho menos un formato de paquetes único, ni siquiera hasta cierto punto compatible , para efectuar la instalación.

Ahora vamos a ver la otra cara de la moneda. Traté de corroborar el hecho de que las aplicaciones no dependieran de algun detalle que no estuviera presente en Chromium , la versión comunitaria del navegador. Al tratar de instalar los ficheros .crx de las aplicaciones antes mencionadas el proceso aborta reportando la necesidad de conectarse al Web Store ... y lo mismo sucede cuando efectivamente la instalación ocurre desde el Web Store ¡qué mala onda! :$

Por cierto se espera la integración de más servicios en versiones posteriores.

El caso SPDY

Ahora quizás llegamos a la cereza del pastel. Se ha formado un revuelo tremendo con el fenómeno  SPDY (se pronuncia en inglés como speedy). ¿Qué es SPDY? Segun el artículo es el monstruo de la laguna verde; comparable con el Internet Explorer 6 pero varios órdenes de magnitud peor. Sin embargo, segun Wikipedia :

SPDY (pronounced speedy) is an experimental networking protocol developed primarily at Google for transporting web content.

La traducción al español es, en pocas palabras, que  SPDY es el protocolo experimental hecho por Google que se piensa remplazará la infraestructura HTTP. Esto quiere decir que en los próximos años puede suceder que la infraestructura subyacente de toda la Internet haya cambiado para bien . Puede que esto sea gracias a Google . Actualmente segun tengo entendido la compañía ofrece 90% de las peticiones de sus servicios con SPDY y el otro 10% con el protocolo HTTP. La razón es que de esta forma pueden tener comparaciones del uso en sistemas en producción y evaluar las mejoras en la calidad del servicio . Si no lo ha entendido , se lo repito :

La Internet del futuro está ya aquí y, si Usted usa Google Chrome o Chromium, entonces ya es cómplice de semejante calamidad :). Si desea comprobarlo use su navegador y acceda a la dirección chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active

La implementación de  WebSockets que ofrecen los navegadores de Google parte de SPDY , segun se cuenta . A diferencia de lo que se pudiera pensar, SPDY no es privativo debido a que se desarrolla por la comunidad alrededor de Chromium . Se encuentra disponible para  descarga el código fuente . Hay librerías para clientes y servidores en  Python,  Java (Tomcat),  un módulo para el servidor web Apache,  Ruby SPDY,  node.js,  Go  Erlang  C SPDY  libcurl. Además se está trabajando en una versión incorporada a Firefox 11. Se maneja la idea de que el protocolo está en vía de estandarización.

Conclusiones

Sinceramente, tengo que decirlo, sospecho que el hecho de que  Michael Muchmore diga ...

Thankfully, Microsoft has abandoned these IE-only features. Let's hope Google follows suit.

... sospecho que se debe a que nunca ha tenido que depurar un flujo de trabajo (o prácticamente cualquier cosa hecha) en Sharepoint , no usa sus galerías de imagenes, supongo que tampoco el Exchange, no consulta sitios hechos con Silverlight , ... en fin no puedo seguir. Me duele la cabeza ya. Establecer una comparación entre lo que hoy hace Google y lo que ha venido haciendo Microsoft durante tanto tiempo , realmente deja mucho que desear. Un punto coincidente es que ambas empresas quieren dominar este sector del mercado de los navegadores web. Todo parece indicar que Google tiene la iniciativa y la innovación a su favor.

Por otra parte , incluso en caso que SPDY sea un éxito , la migración hacia el uso masivo de esa arquitectura implicará una inercia apreciable . Por una parte  los proxies, y la  autentificación tienen particularidades diferentes. Eso implica una actualización paulatina a gran escala del software existente para estos fines. Algunos navegadores e.g.  Opera no parecen estar dispuestos a adoptarlos en un corto plazo. Sin embargo, el peso específico de Google en la web no se puede ignorar. Pronto esta tecnología estará incorporada en dispositivos móviles con el sistema operativo  Android.  Amazon parece incorporar SPDY en su navegador  Silk para  Kindle Fire.