My problem isn't with handling async verification - my callback could probably support it right now, come to think of it. The problem is the ambiguity introduced to higher layers of my code. I want to be able to attempt a subscription, and then raise an exception or something if it fails for whatever reason. I could implement this asynchronously using some kind of delayed error callback, but this is problematic - I'd have to add special cases in various places to handle subs being in a not-yet-subscribed-but-waiting state, where right now I can assume that either there's an active subscription, or I need to resubscribe. There's also the issue of failed verifications - if my program isn't reachable for some reason (firewalls would cause this frequently - I'm writing a feed aggregator application), then there's no way to know that the subscription failed, and I'm stuck with that sub being in limbo indefinitely. "sync" mode gives back a definite error when that happens. (Fixing this would require a change to the spec, actually. Maybe some kind of deadline for the hub to verify the subscription?) So yeah, I think there are still good reasons to keep sync mode.
--Ravi On Sun, Oct 18, 2009 at 11:05 AM, Pádraic Brady <[email protected]>wrote: > 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<http://www.openideurope.eu/> > > > ------------------------------ > *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 >> > >
