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

• ¿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.