18 agosto, 2009

URLPacks, grupos de páginas en el navegador

Tengo la mala costumbre de abrir más y más pestañas con páginas a las que quiero dedicar tiempo en algún momento y que se van acumulando hasta que se llena la barra de pestañas. Entre otros problemas, esta mañana me ha pasado que Google Chrome ha dado un error justo cuando intentaba restaurar todas las que tenía abiertas anteriormente y se ha cerrado. Al volverlo a abrir, ha aparecido una triste pestaña en blanco, algo que, por desgracia, ya me ha pasado anteriormente con Firefox. Aunque he conseguido restaurar las páginas abiertas gracias al historial, me he prometido que iba a resolver de una vez por todas el maldito problema de las pestañas y me he puesto manos a la obra.

La idea es tener una aplicación web muy ligera que acumule URLs relacionados con un tema y que se muestre como si fuese una barra de sub-pestañas. La aplicación está incluida en un único archivo PHP que realiza todas las funciones:

  • mostrar la página del grupo (get). Se muestra como una barra horizontal de enlaces que al ser pulsados cargan la página en la parte inferior, justo como si se tratase del mismo navegador. Además hay botones para limpiar la parte inferior, crear un marcador del grupo o agregar una nueva URL
  • crear un grupo nuevo (post)
  • agregar una nueva url a un grupo existente (put)
  • eliminar una URL del grupo (delete)
  • listar los grupos disponibles (list)
  • mostrar un favicon personalizado para un grupo mostrando las primeras 6 letras del título

Para almacenar la información sobre los grupos, he decidido usar un archivo ZIP de nombre "urlpacks.zip" alojado junto al archivo "urlpacks.php" que aparece a continuación. El ZIP contiene un archivo comprimido por cada grupo; el nombre coincide con el título del grupo; y el contenido son las URLs separadas por un salto de línea: Más sencillo imposible.

<?php
$id= $_GET['id'];
$action= $_GET['action'];
$url= $_GET['url'];

if($action=='') {
 if (!empty($url)) $action="post";
 else $action="list";
}

$zip = new ZipArchive();
if ($zip->open('urlpacks.zip')!==TRUE) {
    exit("cannot open urlpacks.zip\n");
}

switch ($action) {
case 'favicon':
 header('Content-type: image/png');
 $im= imagecreate(16,16);
 $color= imagecolorallocate($im, 255,255,255);
 $string= str_replace(' ','',$id);
 $font = imageloadfont('./terminal9.gdf');
 imagestring($im, $font, 1, -1, $string, imagecolorallocate($im, 0,0,0));
 imagestring($im, $font, 1, 6, substr($string,3), imagecolorallocate($im, 90,90,90));
 imagecolortransparent($im,$color);
 imagepng($im);
 imagedestroy($im);
 exit;
case 'put':
 $data= explode("\n", $zip->getFromName($id));
 array_push($data,$url);
 $zip->addFromString($id, implode("\n",$data));
 header("location:?action=get&id=".$id);
 exit;
case 'post':
 if (!$zip->getFromName($id)) $zip->addFromString($id, $url);
 header("location:?action=get&id=".$id);
 exit;
case 'delete':
 $data= explode("\n", $zip->getFromName($id));
 $key= array_search($url, $data);
 if ($key!==FALSE) array_splice($data,$key,1);
 $zip->addFromString($id, implode("\n",$data));
 header("location:?action=get&id=".$id);
 exit;
case 'list':
 echo "
index
    ";
 for ($i=0; $i<$zip->numFiles;$i++) {
  $item= $zip->statIndex($i);
  echo '
  • ',$item['name'],' ';
    
  $data= explode("\n", $zip->getFromName($item['name']));
    
  if (count($data)>0) {
    
   echo '
      ';
   foreach($data as $link) echo '
    1. ',$link,'
      2. ';
   echo '
    ';
    
  }
    
  echo '
    • ';
 }
 echo '
';
 exit;
default:
}
$zip->close();
$zip->open('urlpacks.zip');
$data= $zip->getFromName($id);
$data= explode("\n", $data);
if (!is_array($data)) $data= Array($zip->getFromName($id));
?>
<head>
<title><?=$id?> :: URLPacks</title>
 <link rel="shortcut icon" href="urlpacks.php?action=favicon&id=<?=$id?>" type="image/png" />
</head>
<body>
<style>
body {
 font: 9px verdana, arial, sans-serif;
 margin:0;
 background:url(/images/grid.gif);
 overflow:hidden !important;
}
.action{
 text-decoration:none;
 color:red;
 font-size:15px;
 font-weight:bold;
}
li {
 padding:0 3px;
 white-space:nowrap !important;
 width:150px;
 overflow:hidden !important;
 border:1px outset gray; border-bottom-width:0;
 float:left;
 margin-right:2px;
 background:white;
}
li a { text-decoration:none; }
li a:focus { background: yellow; }
ul {
 top:25px;
 left:5px !important;
 position:absolute;
 padding-left:0 !important;
}
.icon {
 position:absolute;
 top:3px;
 width:22px;
}
.titulo {
 margin-left:90px;
 margin-top:-16px;
 font: bold 50px calibri, tahoma, verdana, arial, sans-serif ;
 letter-spacing:-1px;
 position:absolute;
}
iframe { border-top:1px solid black; background:white; }
img { border:0; }
</style>

<a title="marcador para grupo <?=$id?>" href="/urlpacks.php?&id=<?=$id?>"><img src="http://www.iconfinder.net/data/icons/oxygen/22x22/actions/bookmark.png" class="icon" /></a>
<a href="about:blank" target="page"><img src="http://www.sonicvisualiser.org/doc/reference/1.3/en/images/icons/erase.png" title="vaciar marco inferior" style="margin-left:24px;" class="icon" /></a>
<a title="agrega nuevo enlace" class="action" href="#" onclick="if (newurl=prompt('URL','')) {location.href='?id=<?=$id?>&action=put&url='+newurl; }"><img src="http://academia.usbbog.edu.co/imagenes/add.png" style="margin-left:50px;" class="icon" /></a>
<span class="titulo"><?=$id?></span>
<ul><?php
foreach($data as $link) {
 echo '
  •  ',$link,' 
    • ';
}
?></ul>
<iframe name="page" src="about:blank" style="width:100%;height:100%;margin-top:50px;" frameborder=0></iframe>
</body>
<?php

$zip->close();
?>

    Para crear un nuevo grupo a partir de la página actual, tengo un bookmarklet en el navegador con el siguiente código:

    javascript:id=prompt('nom',Math.random().toString().substr(2));location.href='http://servidor/urlpacks.php?id='+id+'&url='+location.href;

    En mi servidor de alojamiento funciona perfectamente y he reducido notablemente las pestañas abiertas. Espero que le sea útil a alguien más. Por cierto, he probado varias extensiones de Firefox para conseguir lo mismo, pero ahora mismo estoy usando Chrome y quería mantener yo la información de los grupos (fácilmente descargable mediante http://servidor/urlpacks.zip)

    0 comentarios

    17 agosto, 2009

    La web del Pushbutton (3)

    Traduzco El "tiempo real" se vuelve "real" de Anil Dash. Con este artículo termino la serie de tres aunque continuaré publicando sobre estos temas por su interés. Posiblemente "pushbutton" se convierta en un término tan familiar como "Ajax" en un futuro cercano. Pushbutton es el nombre para lo que creo que será una actualización para la web, en la que cualquier sitio o aplicación pueda entregar mensajes en tiempo real a una audiencia a la escala de la web, usando tecnologías gratuitas y abiertas de bajo coste y sin confiar en una sola compañía como Twitter o Facebook. Las piezas de esta plataforma acaban de unirse para hacer posible un conjunto de nuevas características y aplicaciones que habrían sido casi imposibles de desarrollar en el pasado para un desarrollador web medio. El área más interesante de nuevo desarrollo en la web es la innovación que tiene lugar alrededor de la mensajería en tiempo real, la habilidad de entregar actualizaciones a un sitio web o a una aplicación en uno o dos segundos. Mientras que varios sistemas como Yahoo News Alerts o lectores de fuentes (feeds) como Google Reader han ofrecido formas simples de entregar notificaciones relativamente rápidas, aún están construidas sobre infraestructuras que confían en solicitar repetidamente una página web. Estos sistemas hacen el equivalente a pulsar repetidamente el botón "actualizar" del navegador. Mientras que esos sistemas han estado usando estos métodos ineficientes para entregar actualizaciones, plataformas más modernas como Twitter, Facebook y FriendFeed se han enfocado en construir la infraestructura para la entrega eficiente a gran escala de actualizaciones usando sus propias redes propietarias. Se ha prestado mucha atención al límite de 140 carácteres de Twitter, o al News Feed de Facebook, pero la impresionante tecnología que permite esa experiencia de usuario en estas plataformas es la inmediatez con la que las actualizaciones son entregadas. Los sistemas anteriores, como la mensajería instantánea o el chat, permitían mensajería a tiempo real a cualquiera de uno a uno o a pequeños grupos, pero ha sido difícil entregar esos mensajes en tiempo real a todo el mundo que quería recibirlos a menos que se tuviese mucho dinero, conocimientos e infraestructura. Otra barrera es que, mientras que hay diferentes programas y clientes que te dejan conectarte a Twitter o Facebook con tus propias aplicaciones, no ha habido opciones abiertas y gratuitas para entregar mensajes en tiempo real a una audiencia mayor si no podías, o no querías, confiar en dichas compañías. Pero recientemente, unas pocas piezas clave han encontrado su sitio y que hacen relativamente fácil y económico añadir mensajería en tiempo real como una mejora incremental a sitios y aplicaciones web. Este conjunto de tecnologías relacionadas, que estoy llamando plataforma Pushbutton, producirá un amplio conjunto de nuevas capacidades para usuarios, editores y desarrolladores en la web. Y lo mejor, las tecnologías Pushbutton son gratuitas, abiertas y descentralizadas, significando con ello que la llegada del tiempo real a la web no será dominado por una sola compañía.

    Definiendo Pushbutton

    El concepto y potencial de Pushbutton es como el de Ajax - no es una sola tecnología o invención, es una familia entera de tecnologías, algunas de las cuales han estado en desarrollo o en producción cerca de una década, que juntas permiten esta nueva web en tiempo real. La base de Pushbutton está construida sobre estos sistemas:
    • Atom y RSS: Los formatos de fuente más comunes para sindicación en la web
    • PubSubHubBub y RSSCloud: potentes nuevos distribuidores de mensajes
    • Web Hooks: Simples servicios web para recibir mensajes en lugar de enviarlos
    Los sistemas Pushbutton usan HTTP, el protocolo fundamental de la web, para la comunicación entre estos componentes. La arquitectura de la entrega de mensajes en Pushbutton es fácil de comprender. Antes de Pushbutton, en los sistemas modernos, cuando creas un mensaje (un artículo de un blog, un tweet u otra actualización) se publica en tu fuente RSS o Atom, cada aplicación o sitio que quiere recibir las actualizaciones tiene que solicitar repetidamente la fuente para saber cuando ha cambiado. Opcionalmente se puede notificar ("ping") a algunas aplicaciones para indicarles que ha llegado el momento de recoger las nuevas actualizaciones, pero esto resulta pesado en tiempo y recursos para ambos lados, especialmente si quieres notificar a un montón de gente. En el mejor caso, el sistema que tenemos ahora es análogo a una persona que viene a tu casa y te dice "eh, hay una nueva edición de tu periódico favorito. Debes ir a por ella". Y entonces tienes que ir a la fábrica donde se imprime el periódico a recoger tu copia. En la web Pushbutton, esa persona entrega la noticia entera en tu casa en el instante en el que es publicada. Eso es así porque las aplicaciones que implementan Pushbutton mejorarán el sistema actual entregando no sólo la notificación de que hay un nuevo mensaje, sino el contenido del mismo. Y en lugar de requerir que todas las aplicaciones vengan al sitio a leer la actualización, usan un servidor distribuidor (hub) en la nube para pasar el mensaje directamente a todos los receptores que estén interesados.
    1. Tú, el emisor, creas un mensaje a ser entregado via RSS o Atom
    2. Tu aplicación da el mensaje a uno o más distribuidores PubSubHubBub o RSSCloud que residan en la "nube"
    3. Los distribuidores PubHubSubBub o RSSCloud entregan el mensaje a todos los receptores, las aplicaciones o sitios que hubiesen solicitado actualizaciones de tu sitio
    De esta forma, cada vez que creas un mensaje, un gran numero de receptores pueden consumir ese mensaje casi en tiempo real (normalmente menos de un segundo) sin apenas complejidad. Este tipo de mensajería ha sido posible con tecnologías propietarias o más oscuras, pero el ecosistema Pushbutton supone un gran avance por las siguientes razones:
    • Enviar mensajes requiere solo un cambio pequeño a una fuente RSS o Atom, y una notificación simple y bien definida en lugar de cambios importantes a la aplicación donde creas tus mensajes
    • Recibir mensajes es también muy simple requiriendo sólo que un desarrollador programe la gestión de notificaciones de actualizaciones
    • La mayoría de la complejidad del sistema la gestionan los servidores de distribución, que están bien documentados, implementables en una variedad de lenguajes de programación y construido alrededor de código abierto que probablemente atraiga a una gran comunidad de desarrolladores
    • La mayoría del esfuerzo de escalado y de los costes tienen lugar a nivel de distribuidor, y todos los distribuidores actuales están diseñados para ejecutarse sobre sistemas "nube" económicos como Google App Engine o Amazon EC2
    • El software para enviar, recibir o ejecutar un distribuidor es gratuito, de fuente abierta y está disponible en casi cualquier plataforma
    • Los mensajes enviados sobre plataformas Pushbutton son entregados via HTTP, que es familiar a cualquier desarrollador web y funciona bien sobre cualquier entorno de alojamiento. Todas las peticiones entre las diferentes capas del sistema Pushbutton pueden ser realizadas como simples llamadas REST
    • Las tecnologías Pushbutton pueden ser adoptadas incrementalmente, de forma que las características pueden ser añadidas poco a poco en el lado del receptor o del emisor, sin requerir una actualización completa a la arquitectura de la infraestructura o de la aplicación

    Quién está detrás de Pushbutton

    Las tecnologías Pushbutton han sido creadas y defendidas por algunos de los desarrolladores más creíbles y experimentados de las tecnologías web sociales. A continuación puede verse un breve resumen de la experiencia de dichos componentes:
    • PubHubSubBub fue co-creado por Brad Fitzpatrick y Brett Slatkin de Google. Brad fue el fundador de LiveJournal, y creó tecnologías web sociales tan fundamentales como Memcached u OpenID
    • Las ideas de los pings de actualización XML-RPC, RSS y la RSS Cloud fueron promovidas por Dave Winer, que ha estado desarrollando activamente implementaciones abiertas de estas tecnologías
    • Los Web Hooks han sido evangelizados por Jeff Lindsay, y han sido desplegados por una variedad de distintas compañías y plataformas que desarrollaron dicha técnica por su cuenta
    Además Google ha apoyado el desarrollo por Brad y Brett de PubSubHubBub, y ha permitido su uso sobre el servicio Google FeedBurner. Varias compañías más pequeñas están desplegando grandes partes de esta infraestructura. En breve, algunas de las mejores reputaciones en el desarrollo de sistemas web abiertos han hecho posible Pushbutton, desde las compañías tecnológicas más grandes hasta los desarrolladores independientes más firmes de la web.

    Ideas relacionadas y proyectos anteriores

    Hay un montón de tecnologías existentes que han influenciado la creación y evolución de las tecnologías Pushbutton; Si estás familiarizado con alguno de esos sistemas probablemente ya estés avanzado en comprender parte de lo que Pushbutton intenta conseguir.
    • Twitter Firehose, FriendFeed SUP, el flujo de actualizaciones de TypePad: Estos sistemas de entrega en tiempo real ofrecen el contenido de sus respectivas plataformas como un flujo interminable que los desarrolladores pueden consumir y usar en sus aplicaciones. Actualmente, todos tienen licencias y grados de apertura distintos, y formatos ligeramente diferentes para entregar las actualizaciones, pero han probado la utilidad de la "parte de envío" de la funcionalidad en tiempo real de Pushbutton
    • XMPP (Jabber), NNTP (Usenet), IRC: Estos viejos protocolos de internet han ofrecido varios grados de mensajería en tiempo real y capacidades de distribución de mensajes, y pueden formar una base de experiencia muy útil de la que los desarrolladores de Pushbutton pueden aprender. En algunos casos, elecciones fundamentales de arquitectura sobre seguridad, autenticación o arquitectura fueron hechas cuando la Internet estaba menos poblada y era menos compleja, haciendolas inapropiadas para las aplicaciones de hoy. En todos los casos, estos protocolos son menos conocidos por los desarrolladores web más contemporáneos, y por ello se echan en falta toolkits y recursos de desarrollo, que hace que resulte muy complejo desplegarlos en entornos comunes.
    • TrackBack y Pingback: Estos sistemas de entrega de actualizaciones entre sistemas de publicación (blogs) fueron muy efectivos en permitir conversaciones ricas distribuidas en los primeros días de la blogosfera. Estos han ido disminuyendo en utilidad debido a las implementaciones deficientes o nulas de un sistema de autenticación que han llevado a problemas de spam, y a una falta general de comprensión de su utilidad por parte de los nuevos bloggers. Pushbutton podría ofrecer una oportunidad de restaurar algo del valor de la idea que originó estos sistemas
    • Reverse HTTP podría terminar siendo un componente útil de algunas implementaciones de Pushbutton, como complemento o como compañía a Comet y técnicas relacionadas
    Posibles problemas:
    • ¿Una guerra de formatos? Si estás familiarizado con las comunidades que discuten de tecnologías como fuentes (feeds) sabrás que tienen una merecida reputación de ser contenciosas e, incluso, de abrir acaloradas disputas sobre detalles arcanos. No creo que sea probable que esto pase aquí, ya que sólo hay uno o dos formatos viables para cada capa de la plataforma y los creadores de cada parte han mostrado esfuerzos consistentes y de buena fé para promover la interoperabilidad donde sea posible y la coexistencia pacífica donde sea necesario. En la comunidad Ajax, por ejemplo, la "X" de Ajax a menudo significa JSON en lugar de XML, pero esto no ha dificultado su amplia adopción. También estoy deseando comprometerme personalmente para intentar prevenir cualquier tipo de conflicto interpersonal que pudiera inhibir la adopción de dichas tecnologías. ¿Preocupado? No
    • ¿Temas de escalado? Inevitablemente habrá aprender cosas sobre cómo escalar una capa de distribución intensiva en recursos de un sistema Pushbutton. Pero puesto que los distribuidores trabajan en sistemas de "la nube" que hacen fácilmente disponibles enormes cantidades de recursos computacionales, puesto que los programadores que creen las implementaciones de referencia del software de distribución tienen una gran experiencia haciendo sistemas a escala web y puesto que es relativamente simple introducir nuevos distribuidores conformes se necesite, esto probablemente no resulte un factor importante para la adopción de Pushbutton. ¿Preocupado? No
    • ¿Inquietudes sobre propiedad intelectual? No soy abogado y esto no es consejo legal. Pero ya ha habido un gran interés sobre estos sistemas y es probable que si aparecen malos actores interesados en lanzar sus abogados de patentes sobre esta clase de sistema, probablemente ya estarían demandando a diestra y siniestra. Y los jugadores principales que ya se han implicado han mostrado un deseo consistente en crear sistemas verdaderamente abiertos que no tengan impedimentos de propiedad intelectual. Dicho de forma simple, creo que cualquier lo suficientemente listo para inventar esta clase de tecnologías es lo suficientemente listo para no querer parecer estúpidos demandando a alguien por usarlas. ¿Preocupado? Probablemente no
    • ¿Competición por parte de sistemas centralizados? Las tecnologías Pushbutton no son sólo gratuitas y abiertas, son descentralizadas, por lo que resultan una seria amenaza al modelo "trampa de langostas" del software social. Podemos esperar competición seria de las redes centralizadas que están actualmente construyendo esta clase de sistemas. Si hay una amenaza para la adopción de Pushbutton, esta será probablemente la causa. ¿Preocupado? Sin duda
    • ¿Mala experiencia de usuario? Una de las peores cosas que podemos hacer para usar las nuevas tecnologías es ignorar las implicaciones sociales, personales e incluso políticas de dicho uso. Mensajes que sean entregados inmediatamente no pueden, por su propia naturaleza, ser borrados de todos los sitios en los que aparezcan. La idea de archivar permanentemente estos tipos de mensajes no es familiar para muchos de los usuarios menos familiarizados tecnológicamente. Y cuando vemos algo brillante y nuevo, tenemos la tentación de usar tecnologías porque sí, estemos o no resolviendo un problema real u ofreciendo un valor real. Si Pushbutton recibe un mal golpe pronto a pesar de su potencial tremendo, esta será la razón. ¿Preocupado? Por descontado, sí

    Conclusión

    Tengo una excitación tremenda sobre la nueva era en tiempo real de las aplicaciones web. Mientras que me considero fundamentalmente un persona optimista, tengo un gran escepticismo cuando se trata de dar bombo publicitario sin sentido sobre tecnologías nuevas, de forma que si me permito algo de ese bombo publicitario aquí lo hago con algo de desgana. Pero creo que la web con Pushbutton tiene la oportunidad de dar, a los individuos y a las organizaciones con voces distintas y apasionadas, la habilidad de ser aún más inmediato y expresivo en la web, y después de diez años de publicación en la web, esa es la parte que más me gusta. No tengo dudas de que algunos escépticos dirán que "Pushbutton es sólo PubSubHubBub pero con otro nombre", justo como dijeron en su día "Ajax es XMLHttpRequest pero con otro nombre", y si eso es lo que los chicos super-geeky quieren creer, me parece bien. Y estoy seguro de que aún habrán algunos detalles técnicos por resolver. Pero creo que dando al concepto general una nombre comprensible y dando una explicación comprensible por cualquiera con interés, puede catalizar interés en una nueva área de innovación en la web. Y para ser honesto, cuando veo chicos como Brad Fitzpatrick y Dave Winer trastear sobre el mismo conjunto de problemas, no puedo evitar pensar que algo interesante saldrá de ello. Sobre los próximos días, perfilaré las oportunidades de Pushbutton, exponiendo más de la filosofía que tiene el potencial de darle a Pushbutton algo más de significado que la mayoría de nuevas tecnologías web, y proviendo algunas explicaciones simples de como puedes empezar aprendiendo sobre cómo sacar ventaja de estas tecnologías. Sobre todo espero que ofrecerás tus críticas meditadas, correcciones detalladas e incluso mejores ideas. Seguiré la conversación en los comentarios, en la blogosfera y en un Twitter con el tag #pshb.

    0 comentarios

    14 agosto, 2009

    Reverse HTTP (2)

    Una de las novedosas técnicas que están apareciendo para resolver el problema de la asimetría de HTTP (que el servidor web notifique a los navegadores sobre nuevas actualizaciones como los mensajes de un chat) pasa por aprovechar la tecnología Comet (una conexión persistente entre navegador y servidor que permite que el servidor le envie datos al navegador en cuanto los tenga disponibles y sin que el navegador los haya solicitado explícitamente).

    La idea es que el navegador abre una conexión persistente con el servidor, el cual le asigna una URL (generalmente un subdominio) propia cuyas peticiones son respondidas por el Javascript residente en la página del navegador. De esa forma, la página estática mostrada en el navegador se convierte a todos los efectos en un servidor web capaz de responder a las peticiones entrantes como un servidor web tradicional.
    Traduzco la página reversehttp.net donde se explica con más detalle el funcionamiento de esta técnica.
    Realizar solicitudes para averiguar si hay actualizaciones es malo. Sabemos esto desde que existen los ordenadores. Pero si es así, ¿por qué hay tantos servicios basados en web (SUP, fuentes RSS y Atom, Twitter, etc.) basados en esas solicitudes?
    La respuesta está, en primer lugar, en la asimetría de HTTP. La web está dividida en dos piezas: programas que realizan peticiones y programas que las manejan. Es muy raro ver un mismo programa comportándose a la vez como cliente y como servidor.
    Para arreglar esta asimetría necesitamos ser capaces de actuar como si poder responder a las peticiones HTTP fuese fácil para los programas, de forma que podamos notificar los cambios a las partes interesadas simplemente enviándoles una petición HTTP. Esta es la idea principal de los web hooks.
    Necesitamos hacer fuerza para empujar los procesos que traten con long-polling (Comet) lejos del núcleo de la web y hacia sus límites que es donde tiene que estar.
    Necesitamos hacer que los programas pidan dinámicamente un pedazo del espacio de URLs usando un viejo cliente HTTP y gestionar las peticiones enviadas a las URLs en ese espacio usando ese mismo cliente HTTP.
    Una vez que eso esté hecho, la notificación asíncrona de eventos estará al alcance de cualquier programa que tenga acceso a una librería cliente de HTTP, y los protocolos y servicios sobre HTTP no tendrán que contorsionarse para tratar con la asimetríá de HTTP. Pueden suponer que todo el mundo es un servidor y solicitar y enviar contenidos desde y hacia donde quieran.

    La solución

    Crear un túnel HTTP sobre HTTP de una forma estructurada, controlable y segura. Deja que los programas pidan una parte del espacio de URLs y sirve HTTP, todo por medio de una librería ordinaria cliente de HTTP. Incluso los programas que se ejecutan en entornos muy restrictivos, como Javascript en el navegador, pueden sacar ventaja del servicio ReverseHTTP. La implementación actual provee librerías sencillas y pequeñas para Python, Java y para el Javascript del navegador.

    ¿Por qué no se ha hecho esto antes?

    Esta no es una idea completamente nueva, como parece, aunque no parece haberse usado ampliamente hasta el momento.
    Prácticamente al mismo tiempo que estaba escribiendo ReverseHttp (hacia Mayo de 2008), Donovan Preston de Second Life escribía su versión de la misma idea, que también llamó Reverse HTTP (también conocida como "PTTH"). Su idea es usar la cabecera Upgrade de HTTP 1.1 para intercambiar la dirección del protocolo, lo que funciona bien para entornos distintos del navegador. Él también tiene una solución basada en Comet muy similar a la mía, excepto que la suya usa objetos JSON para describir las peticiones y respuestas HTTP mientras la mia usa los formatos de los mensajes HTTP. Donovan Preston escribe más sobre la variante Second Life aquí, y ha producido, junto a Mark Lentczner, un borrador (Internet-Draft) para el protocolo basado en la cabecera Upgrade.

    Descargas y enlaces

    Addendum

    Es posible comprender mejor la potencia de esta técnica con la demo online disponible en http://www.reversehttp.net/demos/demo.html

    0 comentarios

    13 agosto, 2009

    Web Hooks (1)

    Este es la primera de una serie de tres traducciones de artículos que presentan tres tecnologías relacionadas y novedosas en el ámbito de la programación web. Web Hooks, Reverse HTTP y Pushbutton. La idea principal para habilitarla se describe en este primer artículo sobre webhooks: hacer disponible un script en una URL de forma que un servidor envie ahí información sobre cambios a los que se ha suscrito. Usa el famoso HTTP que siempre han usado los navegadores pero internamente entre servidores web para mandarse información.

    Visita webhooks.org para información más actualizada sobre esta tecnología o el Grupo de Google para debatir

    ¿Qué son los web hooks?

    Los web hooks (enganches web) permiten personalizar, extender e integrar las aplicaciones web que uses con todo lo que puedas acceder programaticamente. Para los desarrolladores web, los web hooks son un patron de diseño simple que sólo requiere la habilidad de hacer peticiones web y almacenar algo de información extra sobre los usuarios. Para los usuarios, los web hooks son una forma de obtener eventos y datos en tiempo real desde sus aplicaciones web. A partir de esto pueden usar esos datos como deseen, permitiéndoles extender e integrar, y empezar a obtener una verdadera visión de la web programable.

    ¿Cómo funcionan?

    Dejando que el usuario especifique una URL para varios eventos, la aplicación hará un POST con los datos a esas URLs cuando esos eventos se produzcan. Con la disponibilidad económica del alojamiento con PHP y con almacenamiento de aplicaciones o scripts aún más simple como el de AppJet o Scriptlets, gestionar los datos del POST se convierte en trivial. Cómo usarlo depende de ti y de lo que quieras conseguir. Entre otras cosas puedes:
    • crear notificaciones para ti o para cualquiera via email, IRC, Jabber, ...
    • poner los datos en otra aplicación (sincronización de datos en tiempo real)
    • procesar los datos y reenviarlos usando la API de la aplicación
    • validar los datos y potencialmente prevenir su uso por la aplicación

    ¿Por qué me debe importar?

    Tan integrada como percibimos la web, la mayoría de aplicaciones operan en silos. Con la aparición de las APIs hemos visto mashups (combinaciones) y algun grado de integración entre aplicaciones. En cualquier caso, no hemos visto la visión de una web programable: una web donde tú como usuario puedes encauzar los datos entre aplicaciones de forma parecida a como se hace en la línea de comandos Unix. Algunos dicen que la respuesta es RSS. Están equivocados. El corazón está en el sitio correcto pero la implementación es errónea. RSS es útil, pero no va a traernos la verdadera web programable.

    Necesitamos una forma simple de extraer datos en tiempo real para dejar que el usuario haga lo que quiera con ellos. Eso significa que nada de consultas repetitivas, nada de restricciones en el contenido, y nada de parsear el XML. Eso significa no usar RSS. Usar HTTP es más simple y más fácil de usar. PHP es un entorno de programación accesible y muy popular, por lo que es probable que se utilice a menudo para programar hooklets... obtener los datos de una petición POST en PHP es tan sencillo como $_POST['algo']. Y hacer la petición al script del usuario es tan simple como realizar una petición HTTP tradicional, algo que los entornos de programación tradicionales ya permiten. De hecho, los web hooks son más fáciles de implementar que una API.

    Ejemplos de implementaciones pueden encontrarse en Sitios como shopify, SurveyGizmo, ZenDesk, GitHub, o Google Code.

    Para saber más

    1 comentarios
    Suscribirse a: Entradas (Atom)


    Últimos links en indiza.com

    Cargando...