3 ms·
Paul - one potential issue is the size of the parent SUP feed itself. For sites like Facebook/Flickr/Netflix which have millions of active users, the size of th
by raghus 18y ago
Paul - one potential issue is the size of the parent SUP feed itself. For sites like Facebook/Flickr/Netflix which have millions of active users, the size of the SUP feed itself might be huge. What are your thoughts on getting around that? Overall, it sounds like a super idea.
- paul 18y agoThe SUP feed is designed to be very compact. The SUP feed on FriendFeed (http://friendfeed.com/api/sup.json http://friendfeed.com/api/sup.json) is only about 8 bytes per entry after gzip. If a service had 10 updates per second (which is faster than Twitter, for example), then a 60 second SUP feed would be 4800 bytes, which is tiny. My expectation is that only large feed consumers (such as FriendFeed or Gnip) will fetch SUP. Smaller ones will probably use an intermediary service such as Gnip since they would only be interested in a small fraction of the updates. They key purpose of SUP is to make it as easy as possible for feed publishers to let the world know which of their feeds have updated.
- joshstaiger 18y agoIf that's a problem, I'd assume you could shard your SUP feeds any number of ways. Say... first 100k feeds reference sup1.json, second 100k reference sup2.json, etc. And given that each RSS/Atom feed <links> to its SUP feed, you could reorganize arbitrarily by updating the link, and the poller should pick it up on the next go-around.