To throw the spanner in the works, what if the Hub refuses synchronous verification with an error? It's the assumption of both approaches being an either/or proposition I'm challenging. They're not. Once Hubs are allowed to support one or the other, Subscribers have no choice but to do the same or actively reject Hubs based on such support.
Whether it introduces ambiguity isn't a possibility, it's a reality right now. The ambiguity is going to exist unless the specification restricts choice - not that I'm saying it should do so, but that at present since there is no restriction Subscribers and/or Hubs must deal with the fallout from such choices. It's the choices that are interesting, and I don't think their impact is yet fully appreciated. The behaviour of a handful of current Hubs is meaningless when in a year's time there could be hundreds - well, we can hope at least ;). 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 7:05:27 PM Subject: [pubsubhubbub] Re: 6.1 sync/async 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 > > > > > > ________________________________ 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 >> >
