3 ms·

Keep in mind that this is only helpful for sites that publish large numbers of feeds. For a site that has only one or two feeds (that is, the typical self-hoste

Keep in mind that this is only helpful for sites that publish large numbers of feeds. For a site that has only one or two feeds (that is, the typical self-hosted weblog or company site), SUP will hurt more than it helps. Basically, it is just a feed where each entry links to an updated feed-- a RSS-formatted sitemap (http://sitemap.org http://sitemap.org) where all the non-feed entries are removed. Sixapart has had a similar interface for a while: http://updates.sixapart.com/ http://updates.sixapart.com/

brlewis 18y ago
If friendfeed queries your SUP feed N times as frequently, the breakeven point for http requests is approximately N regular feeds, assuming those feeds aren't constantly updating. In fact, the SUP feed is small, so it's not at all hard to break even on bandwidth, even with 1 or 2 feeds.
- briansmith 18y ago
  SUP will always have more overhead for a single feed, because it requires more than one (conditional) request: you need one for the SUP feed each time it is polled, and one for the content feed whenever it is changed. Even with 10 feeds, SUP will probably not break even because processing 1 conditional request for the SUP feed is not really less work than processing 10 conditional requests. Each way will have approximately the same network latency (you can process 10 GET requests in one round-trip with pipelining) and the same bandwidth usage (you can stuff a few GET requests and a few 304 Not modified responses in a single packet with pipelining). The same techniques used to efficiently update a SUP feed can be used to keep individual cache entries for each individual feed up to date. Even without pipelining, the benefits are of SUP will be negligible for a site with just a handful of feeds. The fixed cost of implementing SUP and the variable cost of maintaining it needs to be included in the cost analysis, not just the bandwidth. SUP and Sixapart's stream will be useful for big sites. But, they are unnecessary for small ones, at least as far as they've been documented so far.
  - brlewis 18y ago
    Unnecessary I agree. Hurtful was the part I still disagree with, but your point about pipelining http requests is a good one.
    - briansmith 18y ago
      I see. "Hurt more than it helps" wasn't the best wording on my part.
  - deleted 18y ago
    [deleted]
paul 18y ago
Actually, SUP allows sites to point to a SUP feed hosted elsewhere, so small sites can easily contribute to a shared SUP feed hosted elsewhere. I'm going to write some to provide this shared SUP on top of AppJet as soon as I get a chance. It is correct however that SUP is primarily intended for sites that have thousands of feeds, but there are more of those than you may realize.
- briansmith 18y ago
  "hosted elsewhere." Such as @ FriendFeed perhaps? Thanks for pointing that out. I had assume that a business hosting its own feeds would want to host its own SUP feed too, but maybe there are some compelling reasons for not doing that.

brlewis 18y ago

If friendfeed queries your SUP feed N times as frequently, the breakeven point for http requests is approximately N regular feeds, assuming those feeds aren't constantly updating. In fact, the SUP feed is small, so it's not at all hard to break even on bandwidth, even with 1 or 2 feeds.

briansmith 18y ago
SUP will always have more overhead for a single feed, because it requires more than one (conditional) request: you need one for the SUP feed each time it is polled, and one for the content feed whenever it is changed. Even with 10 feeds, SUP will probably not break even because processing 1 conditional request for the SUP feed is not really less work than processing 10 conditional requests. Each way will have approximately the same network latency (you can process 10 GET requests in one round-trip with pipelining) and the same bandwidth usage (you can stuff a few GET requests and a few 304 Not modified responses in a single packet with pipelining). The same techniques used to efficiently update a SUP feed can be used to keep individual cache entries for each individual feed up to date. Even without pipelining, the benefits are of SUP will be negligible for a site with just a handful of feeds. The fixed cost of implementing SUP and the variable cost of maintaining it needs to be included in the cost analysis, not just the bandwidth. SUP and Sixapart's stream will be useful for big sites. But, they are unnecessary for small ones, at least as far as they've been documented so far.
- brlewis 18y ago
  Unnecessary I agree. Hurtful was the part I still disagree with, but your point about pipelining http requests is a good one.
  - briansmith 18y ago
    I see. "Hurt more than it helps" wasn't the best wording on my part.
- deleted 18y ago
  [deleted]

paul 18y ago

Actually, SUP allows sites to point to a SUP feed hosted elsewhere, so small sites can easily contribute to a shared SUP feed hosted elsewhere. I'm going to write some to provide this shared SUP on top of AppJet as soon as I get a chance. It is correct however that SUP is primarily intended for sites that have thousands of feeds, but there are more of those than you may realize.

briansmith 18y ago
"hosted elsewhere." Such as @ FriendFeed perhaps? Thanks for pointing that out. I had assume that a business hosting its own feeds would want to host its own SUP feed too, but maybe there are some compelling reasons for not doing that.