It's simple complexity to handle though - for the Zend Framework I'm using two
classes: Subscriber and Subscriber_Callback. The Subscriber stores a serialised
array of subscription data. The Subscriber_Callback is used to handle any
request to the Callback URL. The partition makes the implementation work for
either sync or async - the verification mode is irrelevant. The difference
really is that the Subscriber stores the subscription details with the
verify_token and HMAC secret before the request commences. The storage backend
can use memcached, for example, or a filestore/database if a completely
reliable store is truly needed.
At the end of the day, zero complication! You need to handle callbacks
somewhere, it costs little to stick the verification handling at the same
location. As an added benefit - it encapsulates request decision making within
a reusable class minimising the work for developers. For example, my sample
code looks like (using async process spawning to handle feed updates - job
queue's better in a real setting):
class CallbackController extends Zend_Controller_Action
{
public function init()
{
$this->_helper->layout()->disableLayout();
$this->_helper->viewRenderer->setNoRender();
}
public function indexAction()
{
$storage = new Zend_Feed_Pubsubhubbub_Storage_Filesystem;
$storage->setDirectory(APPLICATION_ROOT . '/store/subscriptions');
$callback = new Zend_Feed_Pubsubhubbub_Subscriber_Callback;
$callback->setStorage($storage);
// Get callback path parameter to access sub details in store
$callback->setSubscriptionKey($this->_getParam('subkey'));
$callback->handle();
if ($callback->hasFeedUpdate()) {
$data = $callback->getFeedUpdate();
$key = md5($data);
file_put_contents(APPLICATION_ROOT . '/store/updates/' . $key,
$data);
$this->_helper->spawn(array('--key'=>$key), 'process', 'callback');
}
$callback->sendResponse();
}
public function processAction()
{
// Requests here spawned from indexAction
}
}
The above handles verification of subs, unsubs, and sub refreshes, and hooks
into any feed updates that can be offloaded to a spawned job or a job queue.
Runs on a simple file store since I'm only testing. You could take the same
block of code from here, and put into any PHP script and it works just the same
(grabbing the subkey param added to the path of the callback URI would
obviously need to be retrieved differently).
Paddy
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
________________________________
From: R P <[email protected]>
To: [email protected]
Sent: Sun, October 18, 2009 4:30:22 PM
Subject: [pubsubhubbub] Re: 6.1 sync/async
sync is a bit simpler for subscribers. For example, I have a function that I
call to subscribe to a topic through PuSH - it's really convenient to know,
when it returns, whether or not the subscription was successful. With async,
I'd either have to wait for the response in that function (eww), or move that
logic into higher layers of my implementation.
--Ravi
On Sat, Oct 17, 2009 at 11:45 PM, Tim Bray <[email protected]> wrote:
>>I read this one and I'm thinking YAGNI. It seems like the flexibility
>>here adds complexity and doesn't really buy that much. Why not just
>>settle on async and leave it at that?
>
>> -T
>
