I think there are two problems here. 1. The cost of saving state. 2. The efficiency of the subscription process
They are competing with each other. If you look at the two options, it's obvious that asynchronous verification is the most efficient if the cost of saving state is lower than the cost of maintaining two open connections (and the memory used by, e.g., Apache+PHP/Other). In synchronous mode, a Subscriber needs to handle two requests at the same time. One to initiate the subscription, and the second, while the first is held open by the Hub, to handle the verification. In plain numbers - that's doubling the memory my server is consuming for no other reason than the Hub is forcing me to wait for a response to the first. Interestingly - the Hub has the exact same problem. So - is the cost of maintaining some state and offloading to an async process that high? I would argue that Hubs are the best placed to gain efficiencies from sending requests to Subscribers, presumably using a job queue and and some worker processes, so what is one more task on the pile? To a Subscriber, who in most cases is not offloading tasks like this, the cost of synchronous verification is far higher, far more undesireable, and to boot, almost certainly is no less or more complex than asynchronous verifications. There's also a third problem - the more variability we allow, the harder it becomes to handle Hubs as generic services. This is already happening, and that's not a good sign. As a Subscriber, I can't predict what Hubs a Publisher will use, yet I have to figure out what Hubs support, don't support, or impose as additional requirement. Superfeedr (for want of a better example) are a good example. 1. They don't support asynchronous verification (and up to a short time ago returned errors if hub.verify were set to "async" even if the "sync" value were also present as an option). The bracketed scenario was a simple bug that went unnoticed, now fixed, and easy to understand with PuSH being so young. 2. Superfeedr subscription requests must be authenticated via HTTP Basic. This isn't in the specification - not saying it's bad/wrong/invalid, only that a generic Subscriber won't know how the handle it unless they are made aware of Superfeedr's requirement (i.e. build in filtering of Hub Endpoints for special treatment/handling). I'm certainly not implementing that across a future landscape of countless Hubs... I don't expect the average developer in the street to either. 3. They also don't allow HMAC secrets. I am presuming this is because the 0.2 specification is new. For argument's sake, assume there was a Hub who refused to add it. What do I, as a Subscriber, do now? Ignore the Hub? Inform the Publisher? Remember, I'm not filtering URIs for special treatment... I suppose my point is that the more we allow in options/exceptions and unspecified Hub behaviour, the more unlikely it is that Subscribers will have a decent experience. It will become too unpredictable. As for YAGNI, that's definitely in the mix. Sorry for the torrent ;). Just poking at some thoughts I've been having the past week as I finished up a Subscriber and got to testing my own Hub. Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Julien Genestoux <[email protected]> To: [email protected] Sent: Sun, October 18, 2009 6:11:57 AM Subject: [pubsubhubbub] Re: 6.1 sync/async Because in our case, we want sync. We won't 'save' any data as long as the susbcription is not confirmed... so we need sync! -- Julien Genestoux, http://twitter.com/julien51 http://superfeedr.com +1 (415) 254 7340 +33 (0)9 70 44 76 29 On Sat, Oct 17, 2009 at 9: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 >
