3 ms·
So, I'm not sure I completely understand, but I'd like to give it a shot. You hit Feed Y every 30 seconds which is silly because it's probably updated once an
by mdasen 18y ago
So, I'm not sure I completely understand, but I'd like to give it a shot.
You hit Feed Y every 30 seconds which is silly because it's probably updated once an hour or less. Every time you hit Feed Y, you get the RSS for the last 25 postings which takes up bandwidth and possibly processing power for the remote server to generate and processing power and bandwidth on your end to download and consume. BAD! So much waste trying to make sure we get instant updates!
So, Feed Y creates a little "I was last updated at time()" feed. You download that and are transmitting very little unless there's an update in which case you grab the feed. Awesome! Now, I ping 1,000,000 "I was updated at time()" feeds for various Facebook users. . .hmm, that's a ton of HTTP requests and transmission over head.
Scratch that, let's have Facebook create a single feed of all their feeds that have been updated in the past 60, 300, and 600 seconds! So, we hit that every 30 seconds and update then grab whatever is new! Wow! That means that for me to digest updates for all my users who want their Facebook feeding into my service, I just hit one SUP feed and then grab whatever that SUP feed says has changed. That's a lot better than hitting 1,000,000 feeds every 30 seconds.
So, this isn't good for your RSS reader or whatnot, but it would be huge for sites like Friendfeed or anything that feeds Friendfeed since it would reduce the bandwidth and processing on both sides. As they said, they are likely to miss some updates with SUP, but if they can get 90% of the updates that way, they can change from pinging individual feeds every 30 minutes to pining them every 300 minutes and still get new items 10 times as fast by pinging the SUP feeds every 3 minutes.
Cool. Practical. Open. Good-Neighbor vibrations for services they pull from. Could even be game changing as it could allow you to aggregate the data you like over many services in a way that was too bandwidth/processing intensive to scale if everyone started doing it.
- wmf 18y agoIt's such a good idea that it's already been done N times already. http://en.wikipedia.org/wiki/Ping_blog http://en.wikipedia.org/wiki/Ping_blog
- paul 18y agoSUP is conceptually similar, except that instead of pinging a handful of well known feeds, SUP producers declare where their updates are available. Also, by using SUP-IDs instead of urls, the SUP feed is smaller, publishers can keep feeds private, and spam problems are eliminated (ping feeds are generally full of spam blogs). Briefly, SUP adds: - Discoverability (feeds declare where they publish their updates) - Privacy (SUP does not expose a site namespace or secret urls) - Efficiency (each SUP entry is only about 20 bytes) In practice, none of the feed based services other than the blogs use pinging services. Our hope is that with SUP we can get faster updates from the 42 non-blogging services that FriendFeed imports.
- raghus 18y agoI think the difference here is that there's one feed for all users rather than a ping-per-user/blog
- wmf 18y agoBut some of the ping servers already publish SUP-like consolidated feeds.