The functional process outlined in the PubSubHubbub specification is fairly simple, involving only a series of requests and responses among these three parties:
The site or service that is publishing content that someone may want to syndicate at a different location.
The middle layer between the publisher and subscriber. All communication between subscriber and publisher is routed through the hub.
The site(s) that are interested in the content being produced or updated from the publisher.
The hub acts as a mechanism for syndicating content updates from a publisher out to one or more subscribers. Thus, the publisher avoids repeated polling for new or updated content.
With our players in place, we can look at how they interact with one another. The PubSubHubbub process comprising these parties is not time based, so it might take place over a long period of time. This subscription flow takes us through several steps, which we’ll cover next.
Our starting point looks exactly like the traditional flow of a subscriber polling a publisher to obtain new or updated content, as shown in Figure 10-7.
Figure 10-7. PubSubHubbub, step 1: Subscriber polls publisher’s feed
The difference here is in the response object that the publisher sends back to the subscriber. This response will include a forward link to the hub—which ...