despuesdegoogle

Google sigue empujando la web hacia una nueva etapa, en esta ocasión con su propia apuesta para optimizar el venerable protocolo HTTP.
Se trata de SPDY (de Spedy, ¿recuerdan a Speedy González?), una optimización de la negociación que se establece entre navegador y servidor capaz de agilizar el tráfico reduciendo la velocidad de carga de las páginas hasta más de la mitad.

Lo cual refuerza el liderazgo de Google en la creación de una Internet más rápida, condición imprescindible para uno de los principales actores de la nube computacional.
Google lleva trabajando dos años en un proyecto desarrollado con la misma discreción con la que ahora parece que ha empezado a implementarlo en su navegador.
En Download Squad han rastreado la presencia de este nuevo protocolo en Chrome, pero hasta ahora Google no ha hecho ningún anuncio oficial al respecto. Ya saben: en beta continua.

Vía Genbeta

Si ayer Google presentaba un lenguaje de programación, hoy anuncia un protocolo al que ha bautizado como Speedy, tan rápido que ni siquiera puede escribirse completo: SPDY. No viene a sustituir a HTML sino a dotarlo de mayor rapidez minimizando la latencia. En pruebas de laboratorio (en cuya fase se encuentra todavía el proyecto) se han obtenido cargas hasta un 55% más rápidas.

La nota de Google en su blog de Chromium no añade mucho más sino reforzar el carácter experimental de la investigación y el deseo de compartirlo. ¿Dejará Google algún aspecto de la web que no financie, patrocine o lidere? Mientras, bienvenidas las mejoras que repercuten en toda la comunidad, más si estás hechas respetando los estándares:

“We want to continue building on the web’s tradition of experimentation and optimization, to further support the evolution of websites and browsers”

HSTP = Hyperspeech Transfer Protocol, protocolo de transferencia mediante hipervoz. Una nueva dimensión de la web, explorada desde hace unos años por desarrolladores de IBM en la India para ejecutarse en redes de telefonía móvil.

La gran novedad es que los enlaces web no son de texto, como estamos acostumbrados desde el nacimiento de la WWW hace 25 años. Aunque también pueden funcionar como enlace otros objetos (la imagen es seguramente el recurso más socorrido), todavía nos resulta difícil imaginar una web que se active y enlace mediante la voz.

El usuario hablaría a la página móvil que ofrece una serie de opciones y la orden enviada llegaría al sitio encargado de procesarla, que devolvería una determinada respuesta. De forma parecida a como interaccionamos con el típico operador telefónico automático, pero mediante interfaz web en un terminal móvil.

Vía RWW

Existen diversas versiones humorísticas de los distintos códigos estándar que asocia el protocolo HTTP a algún tipo de error en el servidor mientras procesa la petición hecha desde un navegador.
Pero no conocía esta: 16 ilustraciones en Flickr, a las que he llegado vía SitePoint

Dos ejemplos: uno del error 408 (Tiempo de espera agotado), y otro del 415 (Tipo de medio no soportado):
   

La lista de errores:
400 Solicitud incorrecta
401 No autorizado
402 Pago requerido
403 Prohibido
404 No encontrado
405 Método no permitido
406 No aceptable
407 Proxy requerido
408 Tiempo de espera agotado
409 Conflicto
410 Ya no disponible
411 Requiere longitud
412 Falló precondición
413 Entidad de solicitud demasiado larga
414 URL de solicitud demasiado largo
415 Tipo de medio no soportado
416 Rango solicitado no disponible
417 Falló expectativa