End-to-end there are serious weaknesses …

End-to-end there are serious weaknesses in the implementation of the real time web as envisioned by rssCloud and PubSubHubbub. Publishers have it relatively easy, only requiring a ping out to big-scale Hub servers. If anything the burden on publishers is being reduced in this model. One imagines there will be QoS guaranteed hubs in the future, like Superfeedr, not just “open test” servers run by Google with no commitment or road-map to rely on. My concern is on the subscriber end. The story seems better for subscribers than attempting to build reliable polling architecture but how much better? What happens to the subscriber who subscribes to a million feeds in one category. A story spreads amongst those feeds and within a short space of time nearly a million event items from various Hubs are fired off at the subscribers webhook. Sure, multiple events within a short space of time from one hub are packaged into one call but in practice that “short space of time” may prove to be too short to make the packaging effective. Make it too long and you don’t have a real time web. Where, or what, is the thinking on this? Subscribers will need good quality catchers mitts for the data that these hubs are going to be flinging at them. §

Advertisements