"Since the ACL processing logic resides on the server-side, an OSW client is completely unaware of this complexity. A similar flow for webhook-based approaches is fairly complex, so much that there are currently no known implementations. With our approach, a client does not need to construct a so called "capability URL" based on OAuth, such as in the case of PubSubHubBub for private feeds¹. In OSW, you simply start following someone (no added complexity at subscription time, no confirmation required) and notifications will be pushed to the subscriber if the publisher has decided that she can see them."

Note: This is also the case in our architecture.

"Real-time delivery and low latency in notifications are another clear benefit of XMPP, as server federation happens in a one-hop fashion. In contrast to that, the latency of webhook-based protocols such as PubSubHubBub which require a total of 4 network hops before a notifications reaches a subscriber, is highly dependant on the size of the feed and the type of delivery (one or many entries in a single push)."

Note: By 4 network hops the author probably intended 4 packet round-trips.

• not all developers like XML
• developers prefer easy to use APIs
• deployment of XMPP instances is not as easy as standard web infrastructure
• many find it too geeky and won't be bothered
• hosting XMPP is more expensive
• problems with BOSH: Webchat clients frequently breaking. should try web sockets instead?
• we need better Javascript libraries for XMPP
• pointless having a big standard noone wants to implement. have a working implementation first, have the standard come later.

Unfortunately these points have not been published in the paper document but rather presented in voice at the FSW2011 (see the video for the W3C Codebase session). They're also in the OneSocialWeb-for-FSW slides.