Your server will receive a single parameter, the URL of the feed that updated. On receipt of the message you should read the feed, and do what you normally do to locate and present new items to the user. The return value is ignored by the cloud.

You must tell the aggregator something in your POST, it can’t just be a empty. That “something” is the URL that was updated, and you can determine exactly how to present new info whether it is a 200 item feed or a 1 item feed.

“The more I look at PSHB, the more I like how it pushes the actual item to interested clients, as opposed to pushing a request to poll a feed.”

Now we’re back to the greatest debate in syndication formats…. Atom vs. RSS (yes I know PSHB can hook into RSS). Both are good protocols and I’m cool with whichever wins out. To me though, the beauty of RSS Cloud is that it’s so simple, and when it comes to decentralized systems, simplicity usually wins out. While PSHB could potentially be more efficient, the only thing RSS Cloud changes in the RSS picture is that it decreases stale polls in return for teeny tiny POST notifications, which are cheap to begin with.

When you talk about scaling a system like this to 10 million followers, it becomes an issue that has nothing to do with RSS Cloud and is a fundamental issue with notifying that many people, regardless of protocol.

That’s a good idea, but not one that’s part of RSSCloud at this time. The more I look at PSHB, the more I like how it pushes the actual item to interested clients, as opposed to pushing a request to poll a feed.

If the “ping” also carried the 140 character “twit” that could be cached in the cloud then RSS Cloud would address the issues if real-time and scalability.

In it’s current form it’s distributes the ping service and assumes a massive growth of RSS aggregators that are all coordinating well with the distributed/cloud ping service.

Adding the twit to the ping would be a better optimization. The delta would go out into the cloud at the same time and elimiate duplication.

The publishing server tells the client what URL to go to to grab the latest, so, serve up the last couple messages instead of the whole feed if that is necessary.

Besides, that example was given to show that the RSS Cloud system -isn’t- designed for 5 million pings to be sent out. You are missing the “Cloud” element here (the aggregators, Google Reader, Feedburner, Twitter, etc…) and that the publishing server can decide who to syndicate content to in real-time if he or she wishes. In 2009, real-time syndication to millions could be an issue, but in 2015, it may be a piece of cake.

As a general rule, it’s a bad plan to create a technology that assumes a massive infrastructure will spring up to make its astonishing levels of resource consumption possible.