Wer im @podlove_org Publisher das pubsubhubbub Modul nicht nutzt ist doof und stinkt nach Lulu.
Or as Bing™ is phrasing it:
Who is not using the Pubsubhubbub module in the @podlove_org Publisher is dumb and stinks of pee-pee.
PubSub…whatnow? It’s a nerdy name for a nerdy protocol that solves a nerdy problem. Well, it’s a technical problem but both podcast publishers and listeners suffer from it, so stay with me.
When you publish a new episode, it appears on your website immediately. All your RSS feeds are updated simultaneously and the next time a podcast client reads that feed, it will receive your recent episode. But when is that next time? The way RSS works, clients have to regularly check if there is anything new. Imagine walking down to your mailbox every ten minutes. Most of the time, you would find an empty box and would walk back with a sigh of annoyance. That’s what podcast clients have to do: regularly access the feed to see if anything is new—while most of the time, nothing has changed. Ideally the time between publishing an episode and receiving it in the client is as short as possible. So why not check every minute? Because if you do that on a phone, both data plan and battery drain faster than the first glass of German beer you set in front of me after a few months living in Asia. Well, nearly as fast. Also, imagine 10.000 subscribers hitting the feed on your server every minute. Have fun handling that load.
Here you have a dilemma: You want clients and listeners to be notified quickly about new episodes, but the more often clients poll for changes, the worse for people’s mobile devices and your web server.
There are different solutions for each aspect of the problem. Feed proxies like FeedPress deliver the feed for you so you don’t have to worry about it. Some podcast apps have their own server infrastructure and check for changes there instead of on the device, and only inform the device once something has changed. But few of them do, because to do it right is hard and requires quite some time and resources.
Enter PubSubHubbub:
PubSubHubbub is an open protocol for distributed publish/subscribe communication on the Internet. […] Its main purpose is to provide real-time notifications of changes, which improves upon the typical situation where a client periodically polls the feed server at some arbitrary interval. In this way, PubSubHubbub provides pushed HTTP notifications without requiring clients to spend resources on polling for changes.
— https://en.wikipedia.org/wiki/PubSubHubbub
Sounds too good to be true? Here is how you use it: Read the Superfeedr documentation for Publishers and implement it. Kidding. There is already a Publisher module that implements the specification.
So here is what you really do:
- Go to superfeedr.com (or any other PubSubHubbub provider), create a free account and fill out the hub settings.
- In the Publisher, enable “PubSubHubbub Support” on the “Modules” page and enter the Hub URL you just created.
- There is no step 3.
From now on, every time you publish or edit an episode, the Publisher immediately notifies Superfeedr about the change and Superfeedr informs all clients that have subscribed to changes. Keen listeners can start listening to your just-released episode seconds after it has been published.
Podcast clients still need to support this protocol but it’s easy to implement and chances are that they already support it. Now, please don’t go around touting “Eric said it’s easy! Do it now!”. Developers tend to dislike others telling them what’s quick and easy 
This article first appeared in the “Publisher Weekly” Newsletter. Subscribe to get new articles delivered to your inbox.