phil ringnalda

So simple it might even work:

Nick Bradbury joins the chorus saying that the answer to the ads in feeds problem (sucks if you don’t like ads and only want to read some of the posts in an ad-supported feed anyway, but full content plus ads is better than no content if you read offline on the train) is to have both an ads-plus-full-content feed and a no-ads-summary-only feed.

Robert Sayre points out that rather than having two feeds with two URIs and forcing the user to choose at the time they subscribe, aggregators could just send a Detail HTTP header asking for the amount of feed they want, title-only, summaries, or the full meal deal.

It’s an idea with lots of potential, and as his few minutes of PHP shows, not as difficult to implement as many of us would be inclined to think at first. Not only could you solve the ad problem, by having your aggregator default preference for “maximum” with the ad-filled feeds turned down to “summary” except when you have to go offline for a few hours, when you first run “Update all feeds at maximum,” you could improve the lot of other things, as well.

If you subscribe to my Atom feed in Firefox, you pull down 28KB every time Firefox fetches the feed (too often, that is) when with the summaries and content you’ll never see stripped out, it amounts to more like 6KB. Firefox could easily (he said, in the way of people everywhere with no idea how to actually fix a bug) send a Detail: minimum header with every Live Bookmark request, more than making up the extra few characters if just one feed implements it. If you syndicate someone’s feed on your website, with just titles and the summary in a title attribute on the link, sending Detail: summary would save you the trouble of throwing away the content you don’t need.

And having just one URI that negotiates, rather than expecting users to decide which one they want at the time they subscribe, would let a middleman like Bloglines fetch just the maximum feed (reporting just one number for “Subscribers:” rather than making you dig out and add up the numbers for each feed) which it can then parcel out to users according to their preference, rather than fetching your titles, and your titles and summaries, and your titles and summaries and content (and ads).

I’m not quite sure how to handle switching levels and ETags, though: ideally, if I’ve fetched Detail: maximum and I then switch to wanting only Detail: summary, I want a 304 Not Modified if you haven’t added an entry, even though I’m giving you the ETag for a different file. And, probably a lot of the bandwidth savings goes out the window if people frequently switch, since a person grabbing Detail: maximum for the train ride may well have already read fourteen of your fifteen articles. Hmm. Never as easy as I’d like it.