Zend_Feed_Pubsubhubbub_Subscriber implementa un Suscriptor Pubsubhubbub completo, capaz de suscribirse a, o cancelar la suscripción de, cualquier Tema a través de cualquier Hub anunciado por ese Tema. Funciona en conjunto con Zend_Feed_Pubsubhubbub_Subscriber_Callback, que acepta solicitudes de un Hub para confirmar todos los intentos de suscripción o cancelación de suscripción (para evitar el uso indebido por terceros).

Cualquier suscripción (o cancelación de suscripción) requiere la información pertinente antes de continuar, es decir, la URI del Tema (fuente Atom o RSS) al que se va a suscribir para recibir actualizaciones, y la URI del punto final del Hub que gestionará la suscripción y el reenvío de las actualizaciones. El tiempo de vida de una suscripción puede ser determinado por el Hub, pero la mayoría de los Hubs deberían soportar renovaciones automáticas de suscripción comprobando con el Suscriptor. Esto lo soporta Zend_Feed_Pubsubhubbub_Subscriber_Callback y no requiere ningún trabajo adicional por su parte. Aun así, se recomienda encarecidamente usar el tiempo de vida (ttl) de la suscripción proporcionado por el Hub para programar la creación de nuevas suscripciones (el proceso es idéntico al de cualquier nueva suscripción) para renovarla con el Hub. Aunque no debería ser estrictamente necesario, cubre los casos en los que un Hub pueda no soportar la renovación automática de suscripciones y descarta errores del Hub para obtener redundancia adicional.

Con la información pertinente a mano, se puede intentar una suscripción como se muestra a continuación:

$storage = new Zend_Feed_Pubsubhubbub_Model_Subscription;

$subscriber = new Zend_Feed_Pubsubhubbub_Subscriber;
$subscriber->setStorage($storage);
$subscriber->addHubUrl('http://hubbub.example.com');
$subscriber->setTopicUrl('http://www.example.net/rss.xml');
$subscriber->setCallbackUrl('http://www.mydomain.com/hubbub/callback');
$subscriber->subscribeAll();

Para almacenar las suscripciones y ofrecer acceso a estos datos para uso general, el componente requiere una base de datos (más adelante en esta sección se ofrece un esquema). Por defecto, se asume que el nombre de la tabla es "subscription" y utiliza Zend_Db_Table_Abstract internamente, lo que significa que usará el adaptador predeterminado que haya configurado para su aplicación. También puede pasar una instancia personalizada específica de Zend_Db_Table_Abstract al modelo asociado Zend_Feed_Pubsubhubbub_Model_Subscription. Este adaptador personalizado puede ser tan simple en su intención como cambiar el nombre de la tabla a usar, o tan complejo como usted considere necesario.

Aunque este Modelo se ofrece como una solución lista para usar por defecto, puede crear su propio Modelo usando cualquier otra capa de backend o de base de datos (por ejemplo, Doctrine), siempre que la clase resultante implemente la interfaz Zend_Feed_Pubsubhubbub_Model_SubscriptionInterface.

Un ejemplo de esquema (MySQL) para una tabla de suscripción accesible por el modelo proporcionado puede ser similar a:

CREATE TABLE IF NOT EXISTS `subscription` (
  `id` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `topic_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `hub_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `created_time` datetime DEFAULT NULL,
  `lease_seconds` bigint(20) DEFAULT NULL,
  `verify_token` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `secret` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `expiration_time` datetime DEFAULT NULL,
  `subscription_state` varchar(12) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Entre bastidores, el Suscriptor anterior enviará una solicitud al punto final del Hub que contendrá los siguientes parámetros (basado en el ejemplo anterior):

Puede modificar varios de estos parámetros para indicar una preferencia distinta. Por ejemplo, puede establecer un valor de lease seconds diferente usando Zend_Pubsubhubbub_Subscriber::setLeaseSeconds() o mostrar una preferencia por el modo de verificación async usando setPreferredVerificationMode(Zend_Feed_Pubsubhubbub::VERIFICATION_MODE_ASYNC). Sin embargo, los Hubs conservan la capacidad de imponer sus propias preferencias, y por esta razón el componente está deliberadamente diseñado para funcionar con casi cualquier conjunto de opciones con una configuración mínima requerida por parte del usuario final. ¡Las convenciones son geniales cuando funcionan!

Cancelar la suscripción de un Tema sigue exactamente el mismo patrón que el ejemplo anterior, con la excepción de que deberíamos llamar a unsubscribeAll() en su lugar. Los parámetros incluidos son idénticos a los de una solicitud de suscripción, con la excepción de que "hub.mode" se establece en "unsubscribe".

Por defecto, una nueva instancia de Zend_Pubsubhubbub_Subscriber intentará usar un medio de almacenamiento respaldado por base de datos, que por defecto usa el adaptador predeterminado de Zend_Db con un nombre de tabla "subscription". Se recomienda establecer una solución de almacenamiento personalizada cuando estos valores predeterminados no sean adecuados, ya sea pasando un nuevo Modelo que soporte la interfaz requerida o pasando una nueva instancia de Zend_Db_Table_Abstract al constructor del Modelo predeterminado para cambiar el nombre de la tabla utilizada.

Cada vez que se realiza una solicitud de suscripción o cancelación de suscripción, el Hub debe verificar la solicitud reenviando una nueva solicitud de verificación a la URL de Callback establecida en los parámetros de suscripción o cancelación de suscripción. Para gestionar estas solicitudes del Hub, que incluirán todas las comunicaciones futuras que contengan actualizaciones de Tema (fuente), la URL de Callback debería desencadenar la ejecución de una instancia de Zend_Pubsubhubbub_Subscriber_Callback para gestionar la solicitud.

La clase Callback debería configurarse para usar el mismo medio de almacenamiento que la clase Subscriber. Su uso es bastante simple, ya que la mayor parte de su trabajo se realiza internamente.

$storage = new Zend_Feed_Pubsubhubbub_Model_Subscription;
$callback = new Zend_Feed_Pubsubhubbub_Subscriber_Callback;
$callback->setStorage($storage);
$callback->handle();
$callback->sendResponse();

/**
 * Check if the callback resulting in the receipt of a feed update.
 * Otherwise it was either a (un)sub verification request or invalid request.
 * Typically we need do nothing other than add feed update handling - the rest
 * is handled internally by the class.
 */
if ($callback->hasFeedUpdate()) {
    $feedString = $callback->getFeedUpdate();
    /**
     *  Process the feed update asynchronously to avoid a Hub timeout.
     */
}

Como se señaló anteriormente, la clase Zend_Feed_Pubsubhubbub_Subscriber_Callback recibe la clave combinada asociada a cualquier suscripción desde el Hub mediante uno de dos métodos. El método técnicamente preferido es añadir esta clave a la URL de Callback empleada por el Hub en todas las solicitudes futuras usando un parámetro de cadena de consulta con la clave "xhub.subscription". Sin embargo, por razones históricas, principalmente porque esto no estaba soportado en Pubsubhubbub 0.1 (se añadió recientemente solo en la 0.2), se recomienda encarecidamente usar el medio más compatible de añadir esta clave a la URL de Callback, añadiéndola a la ruta de la URL.

Así, la URL http://www.example.com/callback?xhub.subscription=key se convertiría en http://www.example.com/callback/key.

Dado que el método de cadena de consulta es el predeterminado, en previsión de un mayor nivel de soporte futuro para la especificación 0.2 completa, esto requiere algo de trabajo adicional para implementarlo.

El primer paso es hacer que la clase Zend_Feed_Pubsubhubbub_Subscriber_Callback sea consciente de la clave de suscripción contenida en la ruta. Por lo tanto, se inyecta manualmente, ya que también requiere definir manualmente una ruta para este propósito. Esto se logra simplemente llamando al método Zend_Feed_Pubsubhubbub_Subscriber_Callback::setSubscriptionKey() con el parámetro siendo el valor de la clave disponible desde el Router. El ejemplo siguiente muestra esto usando un controlador de Zend Framework.

class CallbackController extends Zend_Controller_Action
{

    public function indexAction()
    {
        $storage = new Zend_Feed_Pubsubhubbub_Model_Subscription;
        $callback = new Zend_Feed_Pubsubhubbub_Subscriber_Callback;
        $callback->setStorage($storage);
        /**
         * Inject subscription key parsing from URL path using
         * a parameter from Router.
         */
        $subscriptionKey = $this->_getParam('subkey');
        $callback->setSubscriptionKey($subscriptionKey);
        $callback->handle();
        $callback->sendResponse();

        /**
         * Check if the callback resulting in the receipt of a feed update.
         * Otherwise it was either a (un)sub verification request or invalid
         * request. Typically we need do nothing other than add feed update
         * handling - the rest is handled internally by the class.
         */
        if ($callback->hasFeedUpdate()) {
            $feedString = $callback->getFeedUpdate();
            /**
             *  Process the feed update asynchronously to avoid a Hub timeout.
             */
        }
    }

}

La forma de añadir realmente la ruta que asignaría la clave añadida al final de la ruta a un parámetro para su recuperación desde un controlador se puede lograr usando una configuración de Route como el siguiente ejemplo con formato INI, para su uso con el arranque de Zend_Application.

; Callback Route to enable appending a PuSH Subscription's lookup key
resources.router.routes.callback.route = "callback/:subkey"
resources.router.routes.callback.defaults.module = "default"
resources.router.routes.callback.defaults.controller = "callback"
resources.router.routes.callback.defaults.action = "index"