Subscribe: Comments on: Joel’s RSS problem
http://weblog.philringnalda.com/2002/10/19/joels-rss-problem/feed/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
apps  authors  big  consuming apps  consuming  feed  hit  index template  index  new  phil ringnalda  phil  ringnalda  template time  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: Joel’s RSS problem

Comments on Joel’s RSS problem



a digital magpie



Updated: 2016-10-24T13:44:47Z

 



By: Kafkaesquí

-0001-11-30T00:00:00Z

As a slightly lower tech, producer’s side solution for the here and now*, is there an option or opportunity to customize ones RSS feed to provide full articles for just the first say 1-2 entries, and have the rest included only as title/link? I may be missing something here (not the first time), but it seems for regularly visited sites, one is normally only reading the most recent few entries. Of course this wouldn’t fully alleviate the issue, but as they used to say: every bit counts, but every bit removed counts more.

* Asked from the perspective of someone who hasn’t had or received an RSS feed in a long time.




By: Phil Ringnalda

-0001-11-30T00:00:00Z

In Movable Type? Sure: MTEntries lastn=”2”, include content:encoded, then MTEntries lastn=”13” offset=”2”, only include description. In CityDesk? Dunno: I’m falling down on my wareblogger job, but I’ve never really looked at it.

Maybe not ideal for someone just adding the feed, but then when I add a feed, I mostly do it from the web page, where I’ve just seen the most recent several entries. That’s why I’m adding it. It sounds to me like it has potential for people who are really being pinched by RSS bandwidth (I overbought, myself, so I need to transfer about 30 times more, not less).




By: Simon Willison

-0001-11-30T00:00:00Z

How about tying aggregators in to a service like weblogs.com or blo.gs ? That way an aggregator could grab the new RSS feed only when new content had been made available.




By: Ian Davis

-0001-11-30T00:00:00Z

Aggregators and publishers should take advantage of the existing HTTP methods of detecting whether a feed has changed or not (Last-Modified and ETags: see Mark Nottingham’s caching tutorial). An aggregator should do a HEAD first to see if the feed has changed since last time it fetched it. If it hasn’t then it doesn’t need to perform the GET, saving badnwidth. Publishers need to make sure their systems produce the correct HTTP headers such – not really all that hard to do but most dynamic systems don’t bother to do it. This is where Moveable Type wins big. Because it publishes all the feeds as static files the web server can generate all the necessary headers automatically. It makes the site more efficient when Google comes for a sniff every couple of days too.

As with the recent redirect debate, other people have gone through these hoops before and their experiences were baked into HTTP.




By: Morbus Iff

-0001-11-30T00:00:00Z

I’d be interested to see which User-Agents are doing him in. Some, like Radio, hit a site every hour it’s open, regardless of if there’s new content or not. Phil – can you get those stats from him?




By: Phil Ringnalda

-0001-11-30T00:00:00Z

Okay, I asked.




By: Phil Ringnalda

-0001-11-30T00:00:00Z

I’d love to be able to handle it completely in HTTP, but the first two steps look pretty damn big to me: first, convince every single author of RSS consuming apps to do it (okay, just the big ones would be a huge help), and second, convince authors of publishing programs to be more careful of what they save: I don’t think Movable Type wins quite as big as you’re thinking it does, since adding a comment rebuilds all index templates (so that the comment count in the main index page will be updated), and RSS is just an index template. Last time my RSS changed was last night, but the mod date for my RSS file is currently 8:52 this morning, and once I hit Post it will be 9:06.




By: Már Örlygsson

-0001-11-30T00:00:00Z

Re Ian Davis’ excellent KISS suggestion:

Instead of HEAD method calls, use conditional GET requests with If-Modified-Since: and/or If-None-Match: headers. These save even more bandwidth than HEAD requests.




By: Phil Ringnalda

-0001-11-30T00:00:00Z

If we could work out the details, weblogs.com/blo.gs would be a great check on ttl: I’d be much more comfortable letting a feed set a 900 minute ttl if I know that my aggregator will ignore the ttl if it spots a ping to weblogs.com in the meantime. How to get it sufficiently fine-grained notification is another question, though: if we’re talking about letting aggregators go below the magic one-hour mark, then they would need to hit the notification service more often as well.




By: Jason

-0001-11-30T00:00:00Z

Why is it harder to ask the authors of RSS-consuming apps to do it in HTTP than to ask them to support something (either the current RSS elements or new ones) that they don’t now? Or, put differently, why create a new ways to do something when the old, reliable ways aren’t used at all? It seems that some of the authors of the current RSS-consuming apps are hitting the same obstacles that early authors of HTML-consuming apps (e.g., browsers) hit, and the appropriate first response would be to see how those authors overcame them (e.g., as Ian said, in HTTP).

(And as for MT redoing the index template every time there’s a new comment, I totally agree; I’ve been pondering a feature request that would set up classes of templates, such as RSS or TrackBack, that would behave slightly differently under different circumstances.)